An Operating Systems Vade Mecum

The communication-kernel approach 315executing simultaneously with any other thread of the same process, that is, letting athread execute until it terminates, blocks for communication, or explicitly waits for acondition. This restriction simplifies the construction of correct programs.4.2 CommunicationThe principal points of differences among proponents of the communication-kernelapproach involve communication. All agree that the facility supported by the kernelmust be extremely efficient, because inter-process communication (including processswitching, not just context switching) is needed to accomplish all operating system functions.It appears that the more facilities the kernel provides for communication, the lessefficient they become.Communication is accomplished by messages sent from one process (actually,from an active thread within the process) to another. Destinations for messages can bespecified by port names or port capabilities. For efficiency, input or bound ports are typicallyused. It is up to the kernel to take a port name or capability and discover where thedestination actually is. One technique is to keep a cache of recently used port names andto broadcast searches when there is a cache miss. If processes can migrate, cache entriescan become obsolete. They are then treated as hints, not absolutes; the kernel canalways resort to broadcast if the hint turns out to be wrong. As an alternative to broadcastingwhen a process must be located, each process can have an original home machinewhose kernel maintains accurate information about its current location. The location ofthe home can be embedded in the process identifier.The space of port names may be sparse to prevent one process from guessing aname used by another. Many different names may refer to the same process; the processmay provide different levels of service to requests made on different identifiers.A sending process directs its messages to entries within the program of the destinationprocess. The sender of the message specifies which entry is meant either implicitly(by which port it sends the message to) or explicitly (as part of the message).Entries may be invoked as remote procedures, in which case in parameters (in the Adasense) are passed by value in the first message, and out parameters are carried back to thecaller in a reply message. Remote procedure call has been championed by many as anelegant way to structure distributed computation. However, some conversations do notfit the procedure-call model. Examples are found in data retrieval, where one queryreturns many responses, one at a time, and in graph algorithms, where more complexactivity takes place. For such cases, a simple message transfer, initiated either by thesender or the receiver, is appropriate. Language-level support can be used to enforcetype security of messages without incurring significant run-time cost.A thread can bind one of its input or bound ports to an entry, which causes incomingmessages to create new threads executing that entry. Alternatively, the thread canexplicitly receive messages. This decision is made dynamically by the destination thread.For large messages, a facility to inspect a small request before deciding to engage in anexpensive transfer (in either direction) is useful.