mod-os@sdcsvax.UUCP (01/16/87)
-- [I lost the return address for this one, sorry. -DL] Concerning IPC: The primitives for message passing we implemented were SEND, RECEIVE, and WAIT. SEND and RECEIVE are non blocking. WAIT will cause a process to block until a message is received or when a time limit expires. Messages are sent to processes, not ports. A process is recognisable by an object residing in a large, distributed virtual memory. Portions of the virtual memory, i.e. volumes, are associated with a machine. Currently, our architecture consists of a tightly coupled multiprocessor with 4 NS32032 processors (max capacity per bus is 32 processors). Each process object contains a message buffer arranged as a finite queue. We have deliberately made the maximum message size small, i.e. less than a 100 bytes. Transference of a by value small message in a tightly coupled multiprocessor can be achieved more quickly than a large message. If large amounts of information are to be sent then the contents of a message should be a capability to some object containing the information. A process cannot be forced to retrieve a message from its message buffer until it wants to. If a message buffer fills then subsequent SENDS will fail. Placing the message buffer in the process object puts it in the same locale of other critical, process state data. Hence switching to a process ensures that the message buffer will be accessible without page faulting. From our point of view, the advantage of supplying nonblocking primitives for message transfer is the opportunity to prevent processes getting hung on the temporary unavailability of other processes, e.g. servers. If a message cannot be sent, some other work can be attended to. While our implementation provides for rapid message transfer within our multiprocessor, there is no speed advantage when the machines are interconnected by a loosely coupled network and communicating processes reside on separate machines. We intend to implement a form of RPC which will not disturb the current semantics or syntax of our message passing protocol to handle "loosely coupled" remote references. --