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.