U. Glaeser

Message-passing IPC shares many characteristics from the single-machine case. Bytes are gathered into an
explicit message. Instead of merely being transferred from one buffer to another on the same machine, the
message goes over the network. Failure of the network or the receiver introduces new problems. The issue of
how long to block the sender is also different, since the time required to confirm delivery of the message in
the remote case can be much longer than in the local case. Issues of message addressing must also be considered.
In a single-machine system, all addressable processes are locally known. In a distributed system, some facility
must be provided to allow the local process to discover the addressable names of remote processes and to send
messages to those names.
Remote procedure call (RPC) faces similar challenges. In a single machine, remote procedures aren’t that
remote. Although they may have a different address space, the local operating system has access to all necessary
facilities of both the calling and called processes. In distributed systems, the caller is on one machine and
the called process on another. Further, the actual transfer of data must take place via messages crossing the
network. One implication is that call-by-reference must be translated to call-by-return-value. Other complexities
exist, including some similar to those for message passing. Another issue is handling partial failures.
Either the caller or the called process can fail independently of the other, requiring the operating system on
the surviving machine to recover.
Shared memory is the hardest common IPC mechanism to provide in distributed operating systems,
because it relies most heavily on hardware characteristics not present in the distributed environment.
Early distributed operating systems made no attempt to provide shared memory across the network;
however, as LANs became more capable, researchers tackled the difficult problems of providing the
semantics of shared memory across the network. This problem spawned vast amounts of research, which
will not be covered in detail here. A slightly closer look at the concept of distributed shared memory will
reveal why this research was necessary.
As before, the distributed system can only communicate via messages. Yet the distributed operating system
must provide the illusion that two processes on different machines are sharing a single piece of physical
memory. The basic approach is to give each process access to a local copy of the memory, then have the
operating systems work behind the scenes to provide a consistent view between the processes. Another
approach is to migrate the memory segments between machines, as needed. This approach can run into
difficulties if processes frequently access the same memory locations. Also, because the overheads of handling
shared memory at the word level are too extreme, distributed shared memory systems must aggregate words
into shared blocks. If the aggregation is too large, false sharing occurs, where one process accesses the first
part of a block while another process accesses the second part. Because the two parts are aggregated into a
single block, the block must migrate back and forth, despite no actual commonly accessed memory locations.
Alternately, memory segments can be replicated. Doing so leads to problems when writes occur. Either
the other copies of the segment must be updated (before they are accessed again), or they must be invalidated.
Either approach requires much bookkeeping and incurs overheads when writes occur. False sharing effects
can also play a role here, since writing to the first word of a block tends to invalidate or cause updates to
the entire block.
Much inventive research has been performed on distributed shared memory, using various techniques
to overcome its challenges. Although distributed shared memory has been demonstrated to be feasible, its
performance, complexity, and limitations have prevented it from becoming popular. Few systems today
provide this facility. Research continues on distributed shared memory, but not as widely as in the past.
Naming Services
Names play an important role in operating systems. Many operating systems support several distinct
name spaces for different purposes. For example, one name space might describe the file system, while
another describes the processes running on a machine, and a third describes the users permitted to
work on the machine. One legacy of Unix systems is that the file name space is used aggressively to
provide name spaces for things that are not classically files, such as devices and interprocess communication
services. (One distributed operating system, Plan 9, relies on this abstraction for all its naming
needs [4].)
© 2002 by CRC Press LLC