\" To run off, use:  troff -ms file | printer
.nr PS 12
.nr VS 14
.tr ~ 
.TL
Distributed Operating Systems
.br
.ps -1
State-of-the-Art and Future Directions
.AU
Sape J. Mullender
.AI
CWI, the Centre for Mathematics and Computer Science, Amsterdam,
\f2and\fP Computer Laboratory, Cambridge University
.NH
INTRODUCTION
.PP
Computing has become only a very minor task for modern computers.  These
days, the computer is mostly used for information storage,
transformation and communication.  Text processing is an excellent
example of modern computer usage.
.PP
The need for better man-machine interaction has dictated much higher
communication bandwidths between machine and user.  Computer prices
rapidly declined, while communication bandwidth remained expensive.
This development naturally led to decentralized computing using personal
computers and work stations with bit-mapped displays and pointing
devices.
.PP
Disk storage technology still suggests large central disks because of
their better price/capacity ratio and their performance characteristics:
Accessing a remote fast disk over a local network can be made faster
than accessing a local slow disk.  Similar arguments apply to keeping
other resources in a central place.  Examples are high-speed laser
printers, phototypesetters, tape drives, and number crunchers.
.PP
These developments have led to fairly typical configurations for
general-purpose distributed systems:  a fast local-area network,
connecting work stations, file servers and printers.  Some systems have
a \f2processor pool\fP, a collection of fast processors which can be
temporarily allocated for compute-intensive jobs, such as compilations.
Many systems have gateways giving access to services over wide-area
networks.
.PP
Several operating systems for such configurations are already
commercially available.  In these systems, however, the user (or the
system manager) must still exercise explicit control over placement of
files, over local or remote execution, etc.  The state-of-the-art for
commercially available systems is centralized systems with a few add-ons
for remote operations.  Systems like this are usually called \f2network
operating systems\fP.
.PP
A distributed operating system is an operating system that runs on a
large number of interconnected machines, but presents to the user an
image of a single very powerful machine.  Today, distributed operating systems
only exist in research environments, although there are one or two
exceptions (The Apollo Domain system is commercially available; systems
such as V and Chorus are distributed in academic circles).
.PP
Distributed systems, having replicated hardware, provide a potential for
fault tolerance and the exploitation of parallelism.  To realise fault
tolerance, files are replicated on several servers so that crashes do
not affect the availability of files; processing is structured so that
after a crash the interrupted work can be redone without causing
inconsistencies.  Parallelism is achieved by splitting up jobs in a
number of parallel processes that communicate and synchronize by
exchanging messages.
.sp
In this paper, we shall describe the state of distributed systems
research and we shall attempt to identify future trends for research in
the area.  Sections 2, 3 and 4, will address communication, fault
tolerance and parallism, respectively.  Section 5 will describe typical
distributed systems structures.  Section 6 gives an overview of
important distributed systems research projects.  Future directions are
discussed in section 7.
.NH
COMMUNICATION
.PP
Traditionally, communication between computer systems was modelled on
the same lines as file i/o.  Just like files are opened, read, written,
or both, and then closed, communication \f2channels\fP were established
(opened), read at one end, written at the other, or the other
way round, or both read and written at each end, and finally the channel
would be broken down (closed) again.
.PP
The network itself usually carries \f2packets\fP of data over the wire
between stations.  In wide-area networks, these packets pass through a
number of intermediate stations on their way to their destination.
Such networks are known as store-and-forward networks; each packet
carries identifying information to tell intermediate stations where to
send the packet next.
.PP
The channel that processes establish is thus an illusion created by the
operating system, it is known as a \f2virtual circuit\fP.  Virtual
circuits are excellently suited for file transfer, for remote login
sessions (connecting terminals to hosts), and for passing output from
one process to another process as input.
.PP
For many years, this was the primary use of the computer network: remote
login, file transfer, and electronic mail and news exchange.  Most
long-haul networks, which were designed in the seventies and early
eighties, therefore adhere to the virtual circuit model of
communication.  It is a model that is simple to understand and it is
convenient for the sorts of things that networks were used for.
.PP
With the coming of distributed computing this model has changed.
The typical paradigm for distributed computing today is the use of
\f2messages\fP.  A message is a block of data that is sent from one
process to another.  Depending on the system messages have a fixed size,
or a size in some range.  Messages need not fit in a single network
packet.
.PP
A fundamental difference between using messages and virtual circuit \- as
far as the operating system is concerned \- is the way in which buffer
management is handled.  When virtual circuits are used, a relative
complicated buffer management mechanism is needed for packet assembly
and disassembly.  This is so because reads to and writes from the
virtual circuit may straddle packet boundaries.  When messages are used,
buffer management is much simpler, since packets contain data from a
single message.
.PP
To illustrate the necessity of simple protocols and simple buffer
management, consider an Ethernet connecting fast work stations,
exchanging messages.  When sending a small message (a hunderd bytes,
say), the time spent in the Ethernet hardware is typically 200 \(*ms,
and time to schedule the receiving process (assuming light-weight
processes) can be on the order of 250 \(*ms.  If the time spent in the
message-passing protocols and the buffer management routines is much
more than another 250 \(*ms, then the efficiency of the message-passing
mechanism is determined primarily by the efficiency of the protocol.  It
is important to realise that the number of machine instructions that can
be executed in 250 \(*ms is small, so protocols must be very simple to
be fast in local-area networks.  Note also that as networks become
faster, the protocol overhead becomes even more the determining factor
for the efficiency of the transport mechanism.
.PP
As another illustration, consider file transfer over a 100 Mbit/s
network (e.g., FDDI).  Let us assume that packets on such a network can
be 10 Kbytes in size.  The wire time for a packet is then 800 \(*ms.
The hardware may need another 800 \(*ms or so to start transmission and to
receive a packet, so the total network hardware time will be on the
order of 1.5 ms.  Again, if protocol times exceed this time by much,
only a fraction of the available network bandwidth will be available for
any single file transfer.
.PP
The fastest protocols using standard Ethernet hardware can do more than
1000 small messages per second between light-weight user processes and transmit
around 5 Mbits/s between user processes using large messages.  The
fastest TCP/IP implementations, in comparison, do not achieve more than 3
Mbits/s.
.PP
Message passing is often embedded in protocols for \f2remote
operations\fP:  A process sends a
request to another, the request is carried out and a response is
returned to the originating process.  Protocols, implementing this model
are known as \f2request/response\fP protocols, \f2client/server\fP
protocol, \f2message-transaction\fP
protocols, or sometimes as \f2remote-procedure call\fP (RPC), although
we shall see that the latter term is not quite appropriate.
The process making the request is usually called a \f2client\fP and the
process carrying out the request a \f2server\fP.
.PP
As it turns out, most of the communication needs in distributed systems
are of a request/response nature: requests range from `are you still
alive,' `list files in a directory,' `run this process,' to `read this
file.'  Even terminal i/o can often be conveniently modelled using
request/response, especially when each subsequent interactive command
(command interpreter, editor, text-processing system, mailer) can run on
a different machine.  When this is the case, it is much more convenient
if the applications \f2fetch\fP their input from the terminal and send
their output to the terminal.  The terminal is treated as a \f2server\fP
fielding and responding to requests for terminal i/o.
.PP
Request/response protocols are also used extensively for the
implementation of remote procedure call mechanisms.  In this mechanism,
a process can call a procedure in another process on a different
machine.  The arguments are \f2marshalled\fP into a message which is
then sent to the remote server.  At the server, the arguments are
unmarshalled, pushed onto the stack and the procedure is called.  The
results are returned in a similar way.  Remote procedure call is thus a
request/response protocol embedded in a programming language.
.NH
FAULT TOLERANCE
.PP
Replicated hardware offers an opportunity for distributed systems to
provide some degree of fault tolerance.  Building fault-tolerant
systems, however, is quite difficult and very much a subject of ongoing
research.
.PP
Fault tolerant file systems are especially important in reliable
distributed systems.  Most of the permanent or semi-permanent state of
the system is stored on files.  After a power failure, the file system
often represents the complete recoverable state of the system.
.PP
Typical failures that file systems must survive are power failures, disk
failures and processor crashes.  During a power failure, the system
naturally doesn't work, but after power is restored a quick recovery of
the file system is important.  During other failures, the system should
continue to be useful.  This means that important files \- if not all
files\-must remain accessible, even if a disk or a file server crashes
unexpectedly.  To achieve this, obviously, files must be replicated so
that, when one copy becomes inaccessible because of a crash, the other
copy can still be used.
.PP
When a crash does occur, work is usually left half done and any crash
recovery mechanism will have to deal with the problem of finding out
exactly at what point the work was interrupted.  In the general case,
only the application can do this, but a distributed system can provide
some assistance by reducing the number of states that the system can be
left in after a crash.
.PP
Such assistance is often realised in the form of \f2atomic
transactions\fP.  Such transactions consist of a group of actions that
are arranged in such a way that either all actions succeed, or \- in the
case of an error \- all actions fail, leaving the system in a state as if
none of the actions were ever attempted.
.PP
An atomic transaction is initiated by a \f2start transaction\fP
operation, which returns a transaction identifier; then a number of
actions are carried out, each one labelled with the transaction
identifier, and, finally, the atomic transaction is either
\f2committed\fP or \f2aborted\fP.  If the commit succeeds, all actions
are made permanent; if the commit fails, or if the transaction is
aborted, all actions are undone.
.PP
There are several possibilities to implement atomic transactions.  One
way is to use \f2intentions lists\fP, lists that describe the changes to
be made to the system when the transaction is committed.  An intentions
list has a boolean flag that indicates whether the transaction it
belongs to has been committed or not.  This flag is only set upon
commit, when the list is complete.  After commit, the intentions list is
carried out.  It is constructed in such a way that, if a crash occurs
while the list is being carried out, it can be carried out again
completely when the system comes back up.  After a crash, uncommitted
intentions lists are discarded.
.PP
Some systems implement \f2nested transactions\fP, atomic transactions
within atomic transactions.  These are very useful to obtain more fine
grain control over failures.  During the execution of a very large
transaction, for instance, not all failures have to cause the abortion
of the transaction as a whole, but can be recovered from within the
transaction.  Using subtransactions for this is very helpful.
.PP
Atomic transactions are now being implemented as basic distributed
systems services.  The Camelot project at Carnegie-Mellon University
[Spector, Pausch, and Bruell, 1988]
and the Quicksilver project at IBM Almaden
[Cabrera and Wyllie, 1987]
are examples of efficient transaction mechanisms in distributed systems.
.PP
Replication leaves objects accessible during arbitrary single-point
failures, but creates complicated new problems: the consistency of
replicated copies and the efficiency of accessing a replicated object.
These two problems are closely related.  It is relatively simple to keep
copies consistent at a large cost in terms of efficiency, but it is very
difficult to make access efficient while maintaining consistency.
.PP
\f2Stable storage\fP
[Lampson and Sturgis, 1979]
is a technique for maintaining replicated copies of
disks in such a way that reads and writes of disk blocks are atomic;
that is, a write succeeds successfully, or a write fails totally,
preserving the previous information on the disk.
.PP
Another technique that makes replication easier is using \f2immutable
objects\fP.  Immutable objects can be replicated
without the difficulties
of multiple-copy update: immutable objects just never need updating.
When immutable objects are used there must naturally be some other
way to reflect change in the system. This is usually provided in
the naming mechanisms: the name of an object is mapped by the naming
mechanism onto the identity of an immutable object. Change is brought
about by changing that map so that the same name refers to another
immutable object. Thus, the problems of fault tolerance and atomicity
are concentrated in one mapping service.
.NH
PARALLELISM
.PP
Distributed systems usually offer mechanisms for applications to exploit
parallelism and use multiple processors to make programs run faster.
Writing parallel programs is a fine art that nobody understands very
well. The exploitation of parallelism, therefore, is limited to only a
few areas.
.PP
An obvious area where parallelism can be obtained easily is in
pipelining. When a process runs in several stages, each stage providing
the input for the next, each stage can simply be made to run on a
different processor. Buffered input and output over the network do the
rest.
.PP
Parallelism is also easily obtained when a job consists of doing a
number of independent things. For instance, when a program has to be
compiled that consists of hundreds of files, it is usually possible to
compile each of the files separately and in parallel. Compilation then
takes as long as it takes to compile the biggest file.
.PP
This kind of parallelism can be detected by programs such as make in
Unix. This program builds an application using a file that describes the
constituing components and their interdependencies. Versions of parallel
make
[Baalbergen, 1986]
often build a graph describing the partial ordering
for things to be done and thus detects the parallelism.
.PP
Several language implementations attempt to provide mechanisms for
expressing or exploiting parallelism. Basically, parallel languages come
in two kinds: languages in which parallelism can be expressed, and
languages that use parallelism internally so they run faster. Examples
exist for both.
.PP
A number of fairly traditional imperative provide some simple support to
create parallel subprocesses. Ada, Modula-2+, and even Algol68 are
examples of such languages. A few languages have been especially
designed for parallel applications. An example of such a language is
Occam. Occam programs are usually executed on a network of Transputers,
fast single-chip processors designed for easy interconnection.
.PP
Practically every  distributed system provides support for parallel
execution on different processors. Many systems even provide a 'parallel
processing resource' in the form of a large number of processors that
can be allocated to jobs as needed. With such a processor bank or
processor pool, work stations can be used exclusively for highly
interactive applications. Some distributed systems designers even clainm
that work stations should be used only to run window-management software
and possibly an editor; all other applications should run in the
processor pool.
.NH
DISTRIBUTED SYSTEMS STRUCTURE
.PP
Many experimental distributed systems are being devveloped on top of an
existing operating system. Usually, this is Unix. Although it seems a
convenient approach to building distributed systems, the result of
building on top of an existing syystem are usually disappointing: the
resulting system is nearly always slow and it is hard to estimate what
portion of the slowness is caused by the host operating system and what
portion is inherent to the distributed system.
.PP
The performance of distributed systems built directly on the hardware is
usually an order of magnitude better. These systems are nearly always
characterised by small operating system kernels providing very limited
functionality and additional functionality provided by application-level
services. Distributed operating systems typically implement the
mechanisms for process managemment and interprocess communication.
.PP
In most of the important distributed operating systems kernels
[Cheriton \f2et al.\fP, 1986; Mullender and Tanenbaum, 1986; Rozier \f2et al.\fP, 1988],
the interprocess communication is usually
blocking and parallelism is achived through leightweigth threads of
ontrol sharing an address space. Semaphores or something similar usually
provide synchronization between these threads. This particular system
structure is one of the few that has survived many experiments with all
sorts of constructs for communication and parallelism in many different
projects. It is one of the few structuring mechanisms that allow
programmers to deal with parallel applications and also allow an
efficient implementation.
.PP
File systems differ very much between systems. One reason is that, after
all these years of file systems development, designing a good file
system is still something of a black art. Very few really high
performance file systems exist and even fewer exist that are
distributed. Another reason is that the technology in this area still
changes. Memory has become much cheaper making extensive caching
possible. Processors have become much faster, making the performance gap
between processor and disk larger. This makes the disk more of a
performance bottleneck.
.PP
A third reason for the differences between file systems is the projected
usage of the file system. The Andrew file system
[Howard \f2et al.\fP, 1988],
for instance, is a file system designed for the use in an academic
environment with many hundreds of users. The file system does whole file
transfer on open and close to reduce the load on the servers. This
works, because in the Andrew environment, nearly all files are small.
The Amoeba file server
[Mullender and Tanenbaum, 1985],
in contrast, has highly
structured files to enable an efficient implementation of optimistic
concurrency control.
.PP
The trend in distributed file systems seems to be towards caching file
systems; file systems designed to make efficient use of large memory
caches and still maintain a proper degree of consistency. To realise
this, quite a few file systems designers have decided to use immutable
version of files, combined with a version replacement mechanism.
.NH
FUTURE DIRECTIONS
.PP
Predicting the future is easy. Doing so with any accuracy is very hard.
This section is the author's attempt to predict the future. It is
unlikely that all predictions come true, but some of them probably will;
which ones those are, only the future can tell.
.PP
Wide-area networks will employ a global addressing scheme and a small
set of standard protocols. Communication setup between any two sites in
the world will be very much like the setup of a telephone call.
Local-area networks will remain largely private; they will be connected
to the wide-area network through gateways. The gateway will provide
firewalls preventing local 'accidents' to penetrate into the wide-area
network, and they can prevent intruders from penetrating into the local
network from the outside. Gateways will also act as protocol converters
so that efficient highspeed protocols can be used locally, tailored to
the applications for which they are used, and standardised efficient
long-haul protocols can be used in the wide-area network.
.PP
Distributed systems will mostly be object oriented
[Lazowska \f2et al.\fP, 1981]
and based on the service model
[Mullender and Tanenbaum, 1986],
that is, objects will be
managed by services, and clients will do operations on those objects
through the mediation of server processes. The system will support a
name space for services and objects. Application programs will never
have to use network addresses directly.
.PP
Workstations will have several powerful processors, a high-quality
display, a keyboard and various other devices for interaction: video
camera, microphone, loudspeaker, pointing device, drawing device. The
work station will be mainly an interaction device; processing and
information storage will take place elsewhere.
.PP
There will be a place for an air-conditioned computed room. File
storage will be located there and also processor farms. It is on the
processors in these farms that most of the computations will take place.
The typical computer in a processor farm will be a multiprocessor, with
a large (hundreds of megabytes) shared memory, accessed through coherent
caches. Multiprocessors will be interconnected by one or several
high-speed networks.
.PP
Air-condtioned computer rooms are needed for several reasons. Very
fast processors dissipate a lot of power and generate a lot of heat.
They will be noisy because of the fans that are used for forced cooling.
Nobody want one of those in the office. Another reason is that, for fast
distributed systems, communication delays must be short; the machines
must therefor be physically close where that is possible.
.PP
Multimedia applications will become important in distributed systems.
Techniques for video-commpression, high-speed local- and wide-area
networks, and better distributed operating system kernels have now made
real-time handling of video, voice and data in a distributed system
feasible. Much research is still required in the areas of user
interfaces, networking, protocols, real-time high-speed file systems,
and the organization of the operating system to deal with multimedia.
.\" reference formatting macros
.de s[   \" start reference
.sp
.in +1m
.ne 3
.ti -1m
..
.de e[   \" end reference
.[-
.in -2m
..
.de []   \" start to display collected references
.if '\\$1'' \{
.NH 1
REFERENCES
.LP\}
..
.de ][   \" choose format
.ie !"\\*([J"" \{\
.    ie !"\\*([V"" .nr t[ 1    \" journal
.    el            .nr t[ 5    \" conference paper
.\}
.el .ie !"\\*([B"" .nr t[ 3    \" article in book
.el .ie !"\\*([R"" .nr t[ 4    \" technical report
.el .ie !"\\*([I"" .nr t[ 2    \" book
.el                .nr t[ 0    \" other
.\\n(t[[
..
.de 0[   \" other
.s[
.ie !"\\*([A"" \\*([A\c
.el .ie !"\\*([E"" \{\
.       ie \\n([E-1 \\*([E, eds.
.       el \\*([E, ed.\}
.el .if !"\\*([I"" \\*([I\c
.ie !"\\*([D"" \& [\\*([Y\\*([U].
.el .if !"\\*([A"" \&.
.ti -1m
.if !"\\*([T"" \\*([T.
.ti -1m
.if !"\\*([V"" Vol. \\*([V\c
.if !"\\*([D"" .if !"\\*([V"" , \\*([D\c
.if !"\\*([D"" .if "\\*([V"" \\*([D\c
.if !"\\*([O"" .if !"\\*([V\\*([D"" , \\*([O\c
.if !"\\*([O"" .if "\\*([V\\*([D"" \\*([O\c
.if !"\\*([V\\*([D\\*([O"" \&.
.e[
..
.de 1[ \" journal article
.s[
.if !"\\*([A"" \\*([A\c
.if !"\\*([D"" \& [\\*([Y\\*([U]\c
\\&.
.ti -1m
.if !"\\*([T""  \\*(lq\\*([T\\*(rq.
.ti -1m
\\f2\\*([J\\fP \\*([V\c
.if !"\\*([N"" \&\|(\\*([N)\c  
.if !"\\*([P"" \&\|:\|\\*([P\c
.if !"\\*([I"" , \\*([I\c
.if !"\\*([D"" , \\*([D\c
\\&.
.ti -1m
.if !"\\*([O"" \\*([O.
.e[
..
.de 2[ \" book
.s[
.ie !"\\*([A"" \\*([A\c
.el \{\
.	ie !"\\*([E"" \{\
.     		ie \\n([E-1 \\*([E, eds.
.     		el \\*([E, ed.\}
.	el .if !"\\*([I"" \\*([I\c\}
.ie !"\\*([D"" \& [\\*([Y\\*([U].
.el .if !"\\*([A"" \&.
.ti -1m
.if !"\\*([T"" \\f2\\*([T\\fP.
.ti -1m
.rm a[
.if !"\\*([I"" .ds a[ \\*([I
.if !"\\*([C"" \{\
.       if !"\\*(a["" .as a[ , \\&
.       as a[ \\*([C\}
.if !"\\*([D"" \{\
.       if !"\\*(a["" .as a[ , \\&
.       as a[ \\*([D\}
\\*(a[.
.ti -1m
.if !"\\*([G"" Gov. ordering no. \\*([G.
.if !"\\*([O"" \\*([O.
.e[
..
.de 3[ \" article in book
.s[
.if !"\\*([A"" \\*([A\c
.if !"\\*([D"" \& [\\*([Y\\*([U]\c
\\&.
.ti -1m
.if !"\\*([T"" \\*(lq\\*([T\\*(rq.
.ti -1m
In
.if !~\\*([E~~ \{\
.       ie \\n([E-1  \\*([E, editors,
.       el \\*([E, editor,\}
\\f2\\*([B\\fP\c
.if !"\\*([V"" , Volume \\*([V\c
.if !"\\*([P"" , pages \\*([P\c
.if !"\\*([I"" \&. \\*([I\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([D"" , \\*([D\c
\\&.
.ti -1m
.if !"\\*([O"" \\*([O.
.e[
..
.de 4[ \" report
.s[
.ie !"\\*([A"" \\*([A\c
.el .if !"\\*([I"" \\*([I\c
.if !"\\*([D"" \& [\\*([Y\\*([U]\c
\\&.
.ti -1m
.if !~\\*([E~~ \{\
.       ie \\n([E-1 \\*([E, editors.
.       el \\*([E, editor.\}
\f2\\*([T\fP.
.ti -1m
\\*([R\c
.if !"\\*([G"" \& (\\*([G)\c
.if !"\\*([I"" , \\*([I\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([D"" , \\*([D\c
\\&.
.ti -1m
.if !"\\*([O"" \\*([O.
.e[
..
.de 5[ \" conference paper
.s[
.if !"\\*([A"" \\*([A\c
.if !"\\*([D"" \& [\\*([Y\\*([U]\c
\\&.
.ti -1m
.if !"\\*([T"" \\*(lq\\*([T\\*(rq.
.ti -1m
\\f2\\*([J\\fP\c
.if !"\\*([P"" \|:\|\\*([P\c
.if !"\\*([C"" , \\*([C\c
.if !"\\*([D"" , \\*([D\c
\\&.
.ti -1m
.if !"\\*([O"" \\*([O.
.e[
..
.de [-   \" clean up after yourself
.rm [A [B [C [D
.rm [E [F [G
.rm [I [J [K
.rm [N [O [P
.rm [R [T [U
.rm [V [W
..
.[]
.[-
.ds [F Baalbergen, 1986
.ds [U \&
.ds [T Parallel and Distributed Compilations in Loosely-Coupled Systems
.ds [A E.\|H. Baalbergen
.ds [J Proceedings of the Workshop on Large Grain Parallelism
.ds [C Providence, RI
.ds [Y 1986
.ds [D October 1986
.][
.[-
.ds [F Cabrera and Wyllie, 1987
.ds [U \&
.ds [T QuickSilver Distributed File Services: An Architecture for Horizontal Growth
.ds [A L.\|F. Cabrera,
.as [A  and J. Wyllie
.ds [I Computer Science Department, IBM Almaden Research Center
.ds [Y 1987
.ds [D 1987
.ds [R RJ5578
.][
.[-
.ds [F Cheriton \f2et al.\fP, 1986
.ds [U \&
.ds [A D.\|R. Cheriton
.as [A , E.\|D. Lazowska
.as [A , J. Zahorjan
.as [A , and W. Zwaenepoel
.ds [T File Access Performance of Diskless Workstations
.ds [J ACM Transactions on Computer Systems
.ds [V 4
.ds [N 3
.ds [Y 1986
.ds [D Aug 1986
.][
.[-
.ds [F Howard \f2et al.\fP, 1988
.ds [U \&
.ds [T Scale and Performance in a Distributed File System
.ds [Y 1988
.ds [D 1988
.ds [A J.\|H. Howard
.as [A , M.\|J. Kazar
.as [A , S.\|G. Menees
.as [A , D.\|A. Nichols
.as [A , M. Satyanarayanan
.as [A , R.\|N. Sidebotham
.as [A , and M.\|J. West
.ds [J ACM Transactions on Computer Systems
.ds [V 6
.ds [N 1
.][
.[-
.ds [F Lampson~ and Sturgis, 1979
.ds [U \&
.ds [T Crash Recovery in a Distributed Storage System
.ds [A B.\|W. Lampson
.as [A  and H. Sturgis
.ds [Y 1979
.ds [D 1979
.ds [I Xerox PARC
.ds [C Palo Alto, CA
.][
.[-
.ds [F Lazowska \f2et al.\fP, 1981
.ds [U \&
.ds [A E.\|D. Lazowska
.as [A , H.\|M. Levy
.as [A , G.\|T. Almes
.as [A , M.\|J. Fischer
.as [A , R.\|J. Fowler
.as [A , and S.\|C. Vestal
.ds [T The Architecture of the Eden System
.ds [J Proceedings Eighth Symposium on Operating System Principles
.nr [P 1
.ds [P 148\-159
.ds [Y 1981
.ds [D December 1981
.][
.[-
.ds [F Mullender and Tanenbaum, 1985
.ds [U \&
.ds [T A Distributed File Service Based on Optimistic Concurrency Control
.ds [A S.\|J. Mullender
.as [A  and A.\|S. Tanenbaum
.ds [J Proceedings of the 10th Symposium on Operating Systems Principles
.ds [C Orcas Island, WA
.ds [Y 1985
.ds [D December 1985
.nr [P 1
.ds [P 51\-62
.][
.[-
.ds [F Mullender and Tanenbaum, 1986
.ds [U \&
.ds [T The Design of a Capability-Based Distributed Operating System
.ds [A S.\|J. Mullender~
.as [A  and A.\|S. Tanenbaum
.ds [J The Computer Journal
.ds [V 29
.ds [N 4
.nr [P 1
.ds [P 289\-300
.ds [Y 1986
.ds [D 1986
.][
.[-
.ds [F Rozier \f2et al.\fP, 1988
.ds [U \&
.ds [A M. Rozier
.as [A , V. Abrossimov
.as [A , F. Armand
.as [A , I. Boule
.as [A , M. Gien
.as [A , M. Guillemont
.as [A , F. Hermann
.as [A , C. Kaiser
.as [A , S. Langlois
.as [A , P. L\o'\'e'onard
.as [A , and W. Neuhauser
.ds [T CHORUS Distributed Operating Systems
.ds [R Report CS/Technical Report-88-7.6
.ds [I Chorus Syst\o'\`e'mes
.ds [C Paris
.ds [Y 1988
.ds [D Nov. 1988
.][
.[-
.ds [F Spector, Pausch, and Bruell, 1988
.ds [U \&
.ds [A A. Spector
.as [A , R. Pausch
.as [A , and R. Bruell
.ds [T Camelot \- A Flexible, Distributed Transaction Processing System
.ds [J Proceedings Compcon 88
.ds [C San Francisco, CA
.ds [Y 1988
.ds [D February 1988
.nr [P 1
.ds [P 432\-437
.][
