|
|
|
| Table 3.8 User state to be changed in a context switch. |
| | | | | | | | | | | | G.P. Registers | | | | | | | F.P. Registers | | | | | | | Other (PSW, etc.) | | | | | |
|
|
|
|
|
|
Figure 3.2
Actions in a remote procedure call. |
|
|
|
|
|
|
|
|
partitions the functions of the operating system into various services, which may be local (within the same processor or workstation) or remote (accessible via a network). A distributed operating system has obvious advantages, as not all services need be present on all systems on the network and various services can be located with appropriate files that need be accessed to provide a particular service. Remote services are accessed via a remote procedure call (Figure 3.2). This remote procedure call (RPC) communicates messages between address spaces. The client (the caller processor) makes a call to the system, and the system automatically generates a link via a message to the server process on the network. This link is referred to as a stub, which packages up the procedure's parameters into a message. At the server, another stub receives the parameters and makes the call to the designated server resource. After executing the service routine, the server returns a result, again via the network, to the requestor. Table 3.9 (from Anderson [20]) shows the various functions involved in the RPC and the percentage of time observed in these functions. Notice that network transfer time is a relatively small amount of the entire RPC processing time. |
|
|
|
|
| Table 3.9 Profile of remote procedure call processing time [20]. |
| | Function | | | Network transfer time | | | Interrupt processing | | | Receiving thread | | | Stub processing | | | Check sums (message validation) | |
|
|
|
