The Topaz System: Distributed Multiprocessor Personal Computing
The Topaz System:
Distributed Multiprocessor Personal Computing
Paul McJones and Andy Hisgen
Digital Equipment Corporation
Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301
September 28, 1987
1
Introduction
ing able to explore the benefits of threads (multiple program
counters executing in an address space) and RPC. More de-
The Topaz distributed operating system, which runs on the
tails about the Topaz operating system, including the reference
Firefly multiprocessor, was built at Digital’s Systems Research
manual for the file system and process manager, are available
Center (SRC) in order to support current computing needs and
in [4].
to provide a basis for research into distributed personal com-
Topaz itself, and most of the application programs designed
puting. In this paper, we give a brief overview of Topaz, and
at SRC, are written in Modula-2+ [5], which extends Modula-
then make some observations based on our use of the system
2 [9] with concurrency [1], exception handling, and garbage
and our plans for the future. These observations fall into two
collection. Topaz RPC is similar to the system described by
areas: our experience with multiprocessing in a workstation,
Birrell and Nelson [2]; it is used not only between machines,
and our views on distribution and autonomy.
but also, with a special transport, between address spaces on
the same machine.
2
Topaz overview
3
Multiprocessing
Topaz runs on the Firefly multiprocessor [8]. The Firefly cur-
rently couples five MicroVAX II processors to 16 megabytes
A distinguishing feature of Topaz is its support for concurrent
of RAM via coherent caches. One of the processors has a Q-
programming within a single application program. Topaz pro-
bus interface, to which are attached controllers for Ethernet,
vides the abstraction of threads, which are scheduled concur-
disks, displays, etc.
rently on the Firefly, so programmers can use them to decrease
The Topaz architecture can be viewed as a hybrid of Berke-
turn-around time by executing independent subcomputations
ley’s 4.2BSD UNIX1 [3] and Xerox’s Cedar [7]. Topaz bor-
in parallel. Threads are also quite useful in structuring pro-
rows the 4.2BSD file system and large-grain process struc-
grams that must deal with asynchrony.
ture, populates these processes (address spaces) with Cedar-
While we are pleased with our use of multiprocessing, it
like threads of control, and interconnects them with Cedar-
has certainly not been a panacea. First of all, five 1-MIPS
like remote procedure call (RPC). (A second implementation
processors rarely equal one 5-MIPS processor. One of our
of Topaz is layered on UNIX; we use it to run various Topaz
applications (a utility for copying file trees, somewhat like
servers on large VAX computers.)
rdist(1)) speeds up by a factor of about 4.7, our parallel
One success of Topaz has been its support both for programs
implementation of make(1) speeds up compilation by a fac-
using the standard 4.2BSD kernel-call interface and for mul-
tor of 2 or 3, and our file system and window manager use
tithreaded programs using a new Topaz operating system in-
multiple processors for read-ahead, write-behind, and pipelin-
terface. These two kinds of programs can run on the same
ing. But a single-threaded program runs at the same speed
machine, share files, send each other signals, and start pro-
as on a MicroVAX II (or, if it is compute-bound, perhaps 6%
cesses of either kind. As a result, we’ve been able to incorpo-
faster because extra CPUs are available to run daemons and
rate many standard UNIX programs (e.g., shells, text editors,
interrupt routines).
and language processors) into our environment, while still be-
While the benefits of multiprocessing are not always spec-
tacular, we found the costs to be reasonable. The extra VLSI
1UNIX is a trademark of AT&T Bell Laboratories
CPUs and caches constitute a modest part of the overall cost of
1
a Firefly (including RAM, controllers, peripherals, power, and
Systems Research Group, University of California at
packaging). Porting the standard UNIX implementation to run
Berkeley, 1983.
on a symmetrical multiprocessor would have been tricky, but
we had the advantage of starting from scratch and being able
[4] Paul R. McJones and Garret F. Swart. Evolving the UNIX
to use the full power of Modula-2+ (including threads) within
system interface to support multithreaded programs. Re-
the operating system.
port 21, Digital Equipment Corporation, Systems Re-
To summarize, we advocate that operating systems provide
search Center, September 1987.
the thread abstraction as a basis for dealing with asynchrony.
[5] Paul Rovner. Extending Modula-2 to build large, inte-
We also advocate selecting the fastest CPU available, and us-
grated systems. IEEE Software, 3(6):46–57, 1986.
ing multiprocessing mainly when it is worth designing concur-
rent algorithms to speed up a specific application (on a work-
[6] M. Satyanarayanan, John H. Howard, David A. Nichols,
station) or to get more throughput (on a multi-user system).
Robert N. Sidebotham, Alfred Z. Spector, and Michael J.
West. The ITC distributed file system: Principles and de-
sign. In Proceedings of the Tenth ACM Symposium on Op-
4
Distribution and Autonomy
erating System Principles, pages 35–50, New York, De-
cember 1985. ACM.
Currently, each Firefly has its own disks and local file system.
References to remote path names are embedded within sym-
[7] D. C. Swinehart, P. Z. Zellweger, and R. B. Hagmann. The
bolic links of the local file system. Accesses to remote files
structure of Cedar. In Proceedings of the ACM SIGPLAN
support the usual UNIX semantics, with no caching of remote
85 Symposium on Language Issues in Programming Envi-
files. We currently simulate a “global” (i.e., laboratory-wide)
ronments, pages 230–244, New York, June 1985. ACM.
name space by following a set of conventions, and running
[8] Charles P. Thacker and Lawrence C. Stewart. Firefly: a
update utilities we have written. This has worked reasonably
multiprocessor workstation. In Proceedings of the Second
well, but a distributed file system presenting a uniform name
International Conference on Architectural Suport for Pro-
space to a set of machines, such as the ITC [6] and Sprite sys-
gramming Languages and Operating Systems. ACM and
tems, is clearly a good idea and is something we plan to im-
IEEE Computer Society, October 1987.
plement.
We believe that the structure of such a global name space
[9] Klaus Wirth. Programming in Modula-2. Springer-Verlag,
needs to permit individual users and groups of users to have
third edition, 1985.
control over their view of the name space. For example, in
a software development environment, a programmer or group
of programmers may need to view a name space that includes
their own experimental versions of a file or of a collection of
related files. Similarly, an organization may want to make
its own decisions about when to incorporate new releases of
software. (IBM Almaden’s Quicksilver design has support for
customized naming, on a user-specific basis.)
References
[1] A. D. Birrell, J. V. Guttag, J. J. Horning, and R. Levin.
Synchronization primitives for a multiprocessor: A formal
specification. In Proceedings of the Eleventh Symposium
on Operating System Principles, New York, 1987. ACM.
To appear.
[2] Andrew D. Birrell and Bruce Jay Nelson. Implementing
remote procedure calls. ACM Transactions on Computer
Systems, 2(1):39–59, February 1984.
[3] William N. Joy, Eric Cooper, Robert Fabry, Samuel J. Lef-
fler, Marshall Kirk McKusick, and D. Mosher. 4.2BSD
system manual.
In UNIX Programmers Manual, 4.2
Berkeley Software Distribution, volume 2C. Computer
2
