Much of our discussion has covered the topic of remote procedure calls where remote refers to a separate machine. This is expected, since the expected use of RPC mechanisms is to communicate across a network with some measure of transparency. However, another use of RPC has emerged in multiprocessor and distributed operating systems. Thus, locality enters the arena as an important issue in designing RPC protocols and systems. Once both the client and server are located on the same machine, other bottlenecks are candidates for optimization as well. This section discusses several areas which become candidates for improvement.
The authors assert that their Lightweight RPC (LRPC) system actually solves the performance problem without reducing the protection offered by the addressing domains of the operating system. Thus, it is not a ``work around'' which fails on protection issues. This section discusses some of the innovative techniques used to implement the LRPC system on the DEC Firefly multiprocessor.
In traditional RPC systems, two different actual threads are used to implement the virtual thread of control: the calling thread in the client and the called thread in the server. When each thread is running on a different machine, this is the only way to perform the required service. On a single machine with one processor, the virtual memory context switch is still required when switching from one addressing domain to another; this can be one of the most significant portions of a context switch, so should not be considered negligible. In a multi-processor environment, a large portion of this remaining overhead can be avoided.
Go Back to the Operating Systems page.
Go Back to the RPC page.