RPC and Threads

Many systems now incorporate support for programmers to break their application processes into lightweight process or ;SPM_quot;threads;SPM_quot;. These are typically implemented by providing multiple execution stacks within the same address space, thus saving on the context switch overheads of saving registers and process state. These packages were developed first and foremost for the programmer creating a server. A server that deals with many RPC clients can be implemented a number of ways. One approach is for a single server process to deal with each request in turn. Another approach is to create a new server process for each request (this is generally costly, and used only for applications with long lived effects). A third approach is to create a pool of servers, and schedule each request to the next free server (or least heavily loaded) in the pool. The way this is done is discussed further in chapter six, and a little in chapter twelve. Once these packages becamse widespread, programmers also used them for an entirely different reason. A threads package allows the programmer to control concurrency. Instead of blocking the client during a call, a server can create a thread, and return immediately to the client, thus providing a reliable message at the level of application access. Or alternatively, a client can create a thread, which makes a call, whilest the ;SPM_quot;main thread;SPM_quot; of the client code continues with other useful work. Combining threads with RPC provides a full general communications system, although this is at the expense of exposign the programmer to the problems of concurrency control. However, if the distributed application has this requirement, these may be unavoidable complexities anyhow. One example of how RPC, threads and messages are itnerrealted is discussed at some length in chapter eight.