The invocation aspect of (how invocations occur across a binding) is independent of the binding model used. Ideally, an framework should be able to accommodate several different methods of data transport within the computational model.
RPC invocations have at least three aspects:
Current operating systems which support as a local communications mechanism tend to use one of two approaches to the problem of carrying a procedure invocation across domain boundaries: message passing and thread tunnelling.
With care, a message passing system using shared memory regions mapped pairwise between communicating protection domains can provide high throughput, particularly by amortising the cost of context switches over several invocations - in other words by having many RPC invocations from a domain outstanding. This separation of information transfer from control transfer is especially beneficial in a shared memory multiprocessor, as described in [27].
The thread tunnelling model achieves very low latency by combining all components into one operation: the transfer of the thread from client to server, using the kernel to simulate the protected procedure calls implemented in hardware on, for example, Multics [28] and some capability systems such as the CAP [9]. An example is the replacement of the original TAOS RPC mechanism by Lightweight [10].
In these cases, the performance advantage of thread tunnelling comes at a price; since the thread has left the client domain, it has the same effect as having blocked as far as the client is concerned. All threads must now be scheduled by the kernel (since they cross protection domain boundaries), thus applications can no longer reliably internally multiplex the CPU. Accounting information must be tied to kernel threads, leading to the crosstalk discussed in section iii.