Each remote procedure call occurs in an execution context called a thread. A thread is a single sequential flow of control with one point of execution on a single processor at any instant. A thread created and managed by application code is an application thread.
Traditional processing occurs exclusively within local application threads. Local application threads execute within the confines of one address space on a local system and pass control exclusively among local code segments, as illustrated in the following figure.
Local Application Thread During a Procedure Call
RPC applications also use application threads to issue both remote procedure calls and runtime calls, as follows:
· An RPC client contains one or more client application threads; that is, a thread that executes client application code that makes one or more remote procedure calls.
· A DCE RPC server uses one server application thread to execute the server application code that listens for incoming calls.
In addition, for executing called remote procedures, an RPC server uses one or more call threads that the RPC runtime provides. As part of initiating listening, the server application thread specifies the maximum number of concurrent calls it will execute. The maximum number of call threads in multithreaded applications depends on the design of the application. The RPC runtime creates the same number of call threads in the server process.
The number of call threads is significant to application code. When using only one call execution thread, application code does not have to protect itself against concurrent resource use. When using more than one call thread, application code must protect itself against concurrent resource use. The following figure shows a multithreaded server with a maximum of four concurrently executing calls. Of the four call threads for the server, only one is currently in use; the other three threads are available for executing calls.
Server Application Thread and Multiple Call Threads
More:
Multithreaded RPC Applications