An Overview of Projects on
DISTRIBUTED SYSTEMS
Alfred J. Lupper, Stefan Ludewig
Computer Science Department
University of Ulm
W-89069 Ulm, Germany
lupper@informatik.uni-ulm.de
- Part 1, 2 and 3 -
The following article gives an overview of past and current projects on distributed operating systems, including some remarkable distributed file systems and distributed programming environments.
I believe this information is current and correct as of the given date, though it certainly is not complete. I apologize for any errors or omissions. If you find errors or you can give a helpful criticism, please let me know. This list will further be maintained at our department and updated continously.
James H. Morris, Mahadev Satyanarayanan, Michael H. Conner, John H. Howard, David S. H. Rosenthal, and F. Donelson-Smith
Andrew is a distributed computing environment for educational purpose that spans over 5000 workstations at Carnegie-Mellon University. The system allows remote file access, printing, electronic-mail and remote program execution. The computing paradigm envisioned in Andrew is a marriage between personal computing and time-sharing. For invoking remote computations the RPC2 remote procedure call (RPC) mechanism has been used extensively in Andrew. The MultiRPC has been developed as an extension to RPC2. The distributed file system AFS is also a part of Andrew. The system distinguishes between local and shared name spaces, which is identical on all workstations.
Model: client/server
Properties: UNIX-compatible, WAN support
Transparency: location, access, replication, concurrency
Running on: Sun Workstations
Date: 1983 - 1985
Literature:
James H. Morris, Mahadev Satyanarayanan, Michael H. Conner, John H. Howard, David S. H. Rosenthal and F. Donel: "Andrew: a Distributed Personal Computing Environment". Communications of the ACM, Vol. 29, No. 3, pp. 184-201, March 1986.
John H. Howard, Michael L. Kazar, Sherri G, Menees, David A. Nichols, M. Satyanarayanan, Robert N. Sidebotham and Michael J. West: "Scale and Performance of a Distributed File System", ACM Transactions on Computer Systems", Vol. 6, No. 1, Feb. 1988, pp. 51-81.
K. C. Cohen, E. Balkovvich, S. Lerman and R.P. Parmelee
Athena is a large distributed system project designed for educational purpose. It is not so much a distributed operating system as a collection of tools to create a friendly and easily manageable distributed user environment under UNIX. It uses client-server interactions with centralized resource servers, and allows users to do most computation locally, storing results in a network file system. Some of Athena's components are the Hesoid nameserver, the Kerberos authentication system and the Palladium printing system.
Model: client/server
Properties: UNIX-compatible
Transparency: access, location
Running on: DEC VAXstation II, IBM RT/PC
Date: 1987
Literature:
K. C. Cohen: "Project Athena: assessing the educational results". Proc. of the ASEE Annual Conference, June 1987, pp. 1279-1282.
S. Lerman: "Project Athena at MIT". EDUCOM Bulletin, 19(4), pp. 5-7.
E. Balkovich, S. R. Lerman and R. P. Parmelee: "Computing in Higher Education: The Athena Experience." Communications of the ACM, Vol. 28, No. 11, pp. 1214-1224, November 1985.
FTP: athena-dist.mit.edu /pub
R.M. Needham, A.J. Herbert and John Wilkes
The CDCS is a distributed file system based on the Cambridge Ring LAN and a processor bank model of computing. It includes the concepts of servers, protection and authentication. The filing system for the CAP is based on the idea of preservation of capabilities. If a program has been able to obtain some capability then it has an absolute right to preserve it for subsequent use. The pursuit of this principle, using capability-oriented mechanisms in preference to access control lists, has led to a filing system in which a preserved capability may be retrieved from different directories to achieve different access statuses, in which the significance of a text name depends on the directory to which it is presented, and in which filing system 'privilege' is expressed by possession of directory capabilities.
Model: client/server, processor pool
Properties: unkown
Transparency: access, failure
Running on: Computer Automation LSI-4
Date: 1977-1982
Literature:
R. M. Needham and A. D. Birrell: "The Cambridge model distributed system". West Lafayette, IN, USA 1977 Computer Lab., Univ. of Cambridge, England, Oper. Syst. Rev. (USA) Spec. Issue, Proceedings of the sixth symposium on operating systems principles, pp. 11-16, Nov. 1977, Vol. 11, No.5.
Sheperd, W. D: "Ancilla-A server for the Cambridge model distributed system". IEEE Software Practice and Experience, 11(11), pp. 1185-1196
J. M. Bacon and K. G. Hamilton: "Distributed Computing with RPC: the Cambridge Approach". Amsterdam pp. 1-14, October 1987
Jeremy Dion: "The Cambridge File Server". ACM Operating Systems Review, October 1980.
Steven T. Vinter, Robert F. Gurwitz, Michael A. Dean, James C. Berets, Ronald A. Mucci and Richard E. Schantz
Cronus is an object-oriented distributed computing environment available from BBN Systems and Technologies. Its major goal is to provide a coherent and integrated environment in which distributed applications can easily be built. Significant Cronus features include:
* a complete environment in which to develop integrated distributed applications;
* delivery of the application development environment in a way that is easy to use and results in reduced development time;
* operation in a heterogeneous environment, including underlying hardware architectures, programming languages and environments, and network technology;
* interoperability and coexistance with existing software, operating systems (such as UNIX and VMS), and applications.
Cronus has been designed as a base for the development of large-scale distributed heterogeneous applications. Although internally the system is object-oriented, this aspect of Cronus is largely hidden from application developers. Most of the details of implementing distributed applications are provided by a combination of code automatically generated from an interface specification (including an RPC interface for clients), library routines, and system components. Cronus has been used in a variety of applications, for example the interconnection of Common Lisp-based expert systems with off-the-shelf database systems and FORTRAN simulations.
Model: heterogeneous, object-oriented
Properties: message passing
Transparency: access, replication, location
Running on: BBN TC2000 nX
Convex ConvexOS
DECstation (MIPS RISC) family Ultrix
DEC VAX VMS, Ultrix
HP 9000 (PA-RISC) family HP-UX
NeXT Mach / NeXTstep
Sun 3, 4 SunOS / Solaris
Prototype ports for other platforms (Alliant, Apollo, Cray, Encore, IBM
RS6000, SGI) may also be available on request.
Date: 1981-
Literature:
R.E. Schantz, R.H. Thomas and G. Bono: "The Architecture of the Cronus Distributed Operating System". IEEE, Proc. of the 6th International Conference on Distributed Computing Systems, pp. 250-259, May 1986
R.F. Gurwitz, M.A. Dean and R.E. Schantz: "Programming Support in the Cronus Distributed System". IEEE, Proc. of the 6th International Conference on Distributed Computing Systems, pp. 486-493, 1986
M. Dean: "Workstations and the Cronus Distributed Operating System". Cambridge, MA, IEEE Computer Society Technical Committee on Operating Systems, Proceedings: Workshop on Workstation Operating Systems, 5-6, November 1987.
John R. Nicol, C. Thomas Wilkes, Frank A. Manola: "Object Orientation in Heterogeneous Distributed Computing Systems", Computer IEEE, pp. 57-67, June 1993.
James C. Berets: "Building Distributed Applications: Why Use Objects?", Workshop on Object-Oriented Modelling in Distributed Systems, NATO AC/243 Panel 11 RSG.1, Quebec, Canada, May 1992.
A. L. Ananda, B. H. Tay, E. K. Koh: "A Survey of Asynchronous Remote Procedure Calls", Operating Systems Review, Vol. 26, No. 2, pp. 92-109, ACM Press, April 1992.
Edward F. Walker, Richard Floyd, Paul Neves: "Asynchronous Remote Operation Execution in Distributed Systems", Proceedings of the 10th Int'l Conference on Distributed Computing Systems, IEEE Computer Society, pp. 253-259, May 1990.
Stephen T. Vinter: "Integrated Distributed Computing Using Heterogeneous Systems", SIGNAL, 43, 10, Armed Forces Communications and Electronics Association, pp. 157-162, June 1989.
Stephen T. Vinter, Nilkanth Phadnis, Richard Floyd: "Distributed Query Processing in Cronus", Proceedings of the 9th Int'l Conference in Distributed Computing Systems, IEEE Computer Society, 414-422, June 1989.
James C. Berets, Richard M. Sands, "Introduction to Cronus", BBN Systems and Technologies, Technical Report 6986, January 1989.
Paul A. Bicknell: "Software Development and Configuration Management in the Cronus Distributed Operating System", Proceedings of the Conference on Software Maintenance-1988, IEEE Computer Society, pp. 143-147, October 1988.
Thomas A. Casey, Jr., Stephen T. Vinter, D.G. Weber, Rammohan Varadarajan, David Rosenthal: "A Secure Distributed Operating System", Proceedings of the 1988 IEEE Symposium on Security and Privacy, IEEE Computer Society, pp. 27-38, April 1988.
Stephen T. Vinter: "Extended Discretionary Access Controls", Proceedings of the 1988 IEEE Symposium on Security and Privacy, IEEE Computer Society, pp. 39-49, April 1988.
Michael A. Dean, Richard M. Sands, Richard E. Schantz: "Canonical Data Representation in the Cronus Distributed Operating System", Proceedings of the IEEE INFOCOM '87, IEEE Computer Society, pp. 814-819, March 1987.
Robert F. Gurwitz, Michael A. Dean, Richard E. Schantz: "Programming Support in the Cronus Distributed Operating System", Proceedings of the 6th Int'l Conference in Distributed Computing Systems, IEEE Computer Society, pp. 486-493, May 1986.
Richard E. Schantz, Robert H. Thomas, Girome Bono: "The Architecture of the Cronus Distributed Operating System", Proceedings of the 6th Int'l Conference in Distributed Computing Systems, IEEE Computer Society, 250-259, May 1986.
FTP: PINEAPPLE.BBN.COM cronus-overview
Ulf Hollberg, B. Mattes, A. Schill, H. Schmutz, B. Schöner, R. Staroste, H. Eberle, W. Stol and Kurt Geihs
DACNOS is a network operating system that addresses two characteristic aspects of today's computing environments: distribution and heterogeneity. DACNOS has aimed at providing efficient and convenient support for the cooperation of homogeneous computing systems. DACNOS does not replace the operating system on the machines. Such a step would have made a large base of software worthless. Consequently, the (DAC)NOS is an add-on to the different operating systems that does not interfere with existing applications, but makes it feasible to have access to remote resources in formerly only-local applications. The RFA Remote File System is a part of the project.
Model: heterogeneous, server/client
Properties: UNIX-compatible, lightweight processes
Transparency: location, access, concurrency
Running on: IBM/370, DEC/VAX, IBM PC
Date: 1990
Literature:
Kurt Geihs and Ulf Hollberg: "Retrospective on DACNOS". Communications of the ACM, April 1990, Vol.33, No. 4, pp. 439-448.
Jean-Pierre Banâtre, Michel Banâtre, G. Lapalme and F. Ployette
Enchère is a distributed agricultural electronic marketing system, that satisfies the criteria of speed, reliability, and fairness between buyers and sellers as required by the market. To achieve this, Enchère combines many original features that up to now have been applied mainly to separate research products: Enchère is a system consisting of a loose network of autonomous microcomputer-based workstations communicating with each other via messages. Reliability is guaranteed by means of atomic actions that are supported by new hardware and software products.
Model: loosely-coupled
Properties: atomic transactions, message passing
Transparency: location, access
Running on: I8086 and I8085 microprocessors connected via Intel Multibus
Date: 1986
Literature:
Banâtre, J. P., Banâtre, M., Lapalme, G. and Ployette, F.: "The design and building of Enchere, a distributed electronic marketing system". Communications of the ACM, 29(1), pp. 19-29.
Schroeder M. D., Birrell A. D., Chase, R. P. Jr. and Needham, R. M.
Grapevine is a system that provides message delivery, resource location, authentication, and access control services in a computer internet. The implementation of Grapevine is distributed and replicated. It is distributed because some of the services provided by Grapevine involve the use of multiple computers communication through the internet. It is replicated in the way that some of the services are provided equally well by any of several distinct computers. The primary use of Grapevine is delivering computer mail, but Grapevine is used in many other ways as well.
Model: loosely coupled
Properties: WAN support, message passing
Transparency: access, concurrency, location
Running on: Alto
Date: 1979-1982
Literature:
Birrell, A. D., Levin, R., Needham, R. M. and Schroeder, M. D.: "Grapevine: an exercise in distributed computing". Communications of the ACM, 25(4), pp. 260-273.
Schroeder, M. D; Birrell, A. D.; Chase, R. P. Jr. and Needham, R. M.: "Experience with Grapevine: the growth of a distributed system". ACM Transactions on Computer Systems, 2(1), Feb. 1984, pp. 3-23.
Andrew D. Birrell, Roy Levin, Roger M. Needham and Michael D. Schröder: "Grapevine: An Exercise in Distributed Computing". Xerox Palo Alto Research Center.
David Notkin, Andrew P. Black, Edward D. Lazowska, Henry M. Levy, Jan Sanislo and John Zahorjan
HCS is a software structure created for interconnecting heterogeneous computer systems, and was designed to address the problems of heterogeneity that typically arise in research computing environments. A set of network services is provided that are made available to a heterogeneous collection of client systems through the use of HCS RPC and HCS naming facilities, called HNS. The HCS remote computation service provides a generic mechanism by which services can be executed remotely. HCS also includes a distributed file system, which is represented by two destinct efforts, a generalized filing service that stores files in multiple representations, and an approach based on the naming facility, where existing local file systems are used to store data.
Model: heterogeneous, server/client, loosely-coupled
Properties: UNIX-compatible
Transparency: location
Running on: VAX, SUN, PC-AT
Date: 1988
Literature:
David Notkin, Andrew P. Black, Edward D. Lazowska, Henry M. Levy, Jan Sanislo and John Zahorjan: "Interconnecting heterogeneous computer systems". Communication of the ACM, Vol. 31, No. 3, pp. 258-273, March 1988.
C. Brian Pinkerton, Edward D. Lazowska, David Notkin and John Zahorjan: "A Heterogeneous Distributed File System". Paris, France 1990, IEEE Proc. 10th International Conference on Distributed Computing Systems, May-June 1990, pp.424-431.
J. Nehmer, D. Haban, F. Mattern, D. Rombach, and D. Wybraietz
The INCAS multicomputer project aims at the development of a comprehensive methology for the design and implementation of locally distributed systems. A structuring concept for distributed operating systems has been developed and integrated into the system implementation language LADY. The concurrent high-level programming language CSSA, based on the actor model, has been designed for the implementation of distributed applications. A substantial effort in the INCAS project is directed towards the development of a distributed test methodology.
Model: workstation, homogeneous, loosely-coupled, actor model, modular
Properties: point-to-point, datagram, pipes or streams, multicast, synchronization, mediumweight
Transparency: location, access, concurrency
Running on: MC 68000 multiprocessors, Sun
Date: 01.01.85 - ?
Literature:
J. Nehmer, D. Haban, F. Mattern, D. Rombach, D. Wybraietz: "Key Concepts of the INCAS multicomputer Project". IEEE Transactions on Software Engineering Vol. SE-13, No. 8, 1987.
Distributed Computing Environment
University of Colorado, USA
Michael F. Schwartz
Three goals for resource discovery:
1. It is to consider very large environments, spanning national and international network. Such
environments place stringent scalability requirements on the algorithms that can be used
2. It is to avoid imposing artificial constraints on the resource space organisation
3. It is to minimize the need for global administrative argument over protocols, information
formals, and organisational structures
Model: loosely-coupled
Properties: WAN support, crash recovery
Transparency:
Running on: UNIX-Wokstations
Date: 1988-?
Literature
Michael F. Schwartz: "Resource Discovery and Related Research at the University of Colorado", Internal Report CU-CS-508-91, Department of Computer Science, University of Colorado, USA, January 1991.
M.F. Schwartz: " Autonomy vs. Interdependence in the Networked Resource Dicovery Project", Position paper, ACM SIGOPS European Workshop, Cambridge, England, September 1988.
M.F. Schwartz: " The Networked Resource Discovery Project", Proc. of the IFIP XI World Congress, pp. 827-832, San Fransisco, California, August 1989.
FTP: latour.colorado.edu ftp.cse.ucsc.edu, /pub/RD.Papers /pub/tcos
Rob Pike
Plan-9 is a distributed computing environment. It is assembled from separate machines acting as CPU servers, file servers, and terminals. The pieces are connected by a single file-oriented protocol and local name space operations. Plan-9 is a general-purpose, multi-user, portable distributed system implemented on a variety of computers and networks. It lacks a number of features often found in other distributed systems, including a uniform distributed name space, process migration, light-weight processes, distributed file caching, personalized workstations and support of X-windows.
Model: server/client, loosely coupled
Properties: message passing
Transparency: location, access
Running on: SIG MIPS, MC68020
Date: 1987
Literature:
Rob Pike, David Leo Presotto, Ken Thompson and Howard Trickey: "Plan 9 from Bell Labs". Bell Labs
FTP: research.att.com
Distributed Computing Environment
Imperial College London, ESPRIT project 2080, UK
Jeff Kramer, Jeff Magee,and Anthony Finkelstein
REX supports the construction of reconfigurable and extensible parallel and distributed systems. The main principle underlying this architecture is that systems should be described, constructed and modified as a structural configuration of interconnected component instances. The structure should be discribed by a separate explicit configuration language allowing components to be programmed in a range of hetergeneous programming languages.
Model: client/server, loosely-coupled
Properties: replication, message-passing, traditional hierarchical naming
Transparency:
Running on: Sun-3, Sun-4
Date:
Literature
REX Technical Annexe, ESPRIT Project 2080, European Economic Comission, March 1989.
Jeff Kramer, Jeff Magee, Morris Sloman, and Naranker Dulay: "An Overview of the REX Software Architecture". Department of Computing, Imperial Cllege of Science, Technologie and Medicine, 180 Queen's Gate, London, UK.
FTP: gummo.doc.ic.ac.uk
Priscilla M. Lu
RIDE has been designed and implemented for the UNIX operating system to provide sharing of remote files, remote process invocation and interprocess communication in a distributed computing environment. The system is designed to support a uniform interface for both local and remote access in a network. The user programs can be executed in a single or multiple machine environment without any program modification. Ride supports a progam level interface that gives programmers a greater degree of flexibility in handling remote execution sequences and synchronisation.
Model: minicomputer, heterogeneous, client/server, loosely-coupled, partially
integrated, monolithic
Properties: UNIX-compatible, pipes or streams, datagram, synchronization,
encryption, identity based, heavyweight, traditional hierarchical
naming, channels
Transparency: location, access, naming
Running on: different Unix Maschines
Date: 01.01.79 - ?
Literature:
P.M. Lu; "A system for resource sharing in a distributed environment - RIDE". Proc. IEEE Computer Society 3rd COMPSAC, IEEE, New York, 1979.
Douglas Comer, Thomas P Murtagh and John T. Korb
TILDE is an universal distributed file system which provides transparent access and location independent names at tree level. Caching is supported but no replication. The fetch grain are pages. The goal of the Tilde project was to explore general purpose distributed computing system in which the user interface hides the heterogeneous nature of the underlying hardware. A file naming sheme in which names are independent of the processors on which files reside must be part of such an interface. The Tilde file naming mechanism interprets file names relative to an environment maintained by the user rather than a single system-wide environment.
Model: loosely-coupled, heterogenous
Properties: traditional hierarchical naming
Transparency: access, naming
Running on:
Date: 1984-1986
Literature
Douglas Comer and Thomas P Murtagh: "The Tilde File Naming Scheme", Los Angeles, CA, IEEE Computer Society, 6th International Conference on Distributed Computing Systems, May 1986, pp.509-514 .
Douglas Comer and Ralph E. Droms: "Tilde Trees in the UNIX Environment", Tilde Project, Purdue University, January 1985.
Douglas Comer, John T. Korb, Thomas Murtagh, and Walter Tichy: "The TILDE Project", 1984 Purdue University, CSD-TR-500, November 23, 1984.
M.R. Brown, K. Kolling and E.A. Taft
Alpine is a distributed file system, that supports atomic transactions and is designed to operate as a service on a computer network. Alpine's primary purpose is to store files that represent databases. An important secondary goal is to store ordinary files representing documents, program modules, and the like. Unlike to other file servers described in the literature, Alpine uses a log-based technique to implement atomic file update. Another unusual aspect of Alpine is that it performs all communication via a general-purpose remote procedure call facility. Alpine is written in Cedar.
Model: client/server
Properties: atomic transactions, lightweight processes
Transparency: access, location
Running on: Dorado
Date: 1983
Literature:
M.R. Brown, K. Kolling and E.A. Taft: "The Alpine file system". ACM Transactions on Computer Systems, Vol. 3 No. 4, Nov. 1985, pp. 261-293.
P. Milligan, L. C. Waring, and A.S.C. Lee
BIFS is filing system for multiprocessor based systems, which provides a set of file models, sequential, indexed sequential and random access, together with a range associated operations. The files may have simple or structured record types. The filing system has the ability to use one or more storage devices. The filing system is resident on a host processor and is connected to a communications shell. The current version of the shell takes the form of a simple packet switching scheme. The filing system is resident on a part of the multiprocessor and operates in a busy waiting manner, scanning the user input channels for requests.
Model: multiprocessor, non-shared memory
Properties: parallel interleaved files
Transparency: location, access
Running on: Inmos Transputers
Date: 1991
Literature:
P. Milligan, L. C. Waring, and A.S.C. Lee: "BIFS: A Filing System for Multiprocessor Based Systems". North Holland, Microprocessing and Microprogramming 31 (1991), pp. 9-12.
Peter C. Dibble and Michael L. Scott
Bridge is a parallel multiprocessor file system that has been designed to eliminate the limitations, which are influenced by the performance of the processor running the file system. This is achieved by spreading both data and file system computation over a large number of processors and disks. To access the effectiveness of Bridge it was used to implement several data-intensive applications, including a parallel external merge sort. Bridge is an implementation of a parallel interleaved file system on the BNN Butterfly Parallel Processor. Bridge has two main functional layers. The lower layer consists of a Local File System (LFS) on each of the processors with disks. The upper layer is called the Bridge Server; it maintains the integrity of the file system as a whole and provides the initial interface to user applications. Except for a few functions that act on the state of the server itself, the Bridge Server interprets I/O requests and dispatches to the appropriate LFSs.
Model: multiprocessor
Properties: interleaved files
Transparency: access, location
Running on: BBN Butterfly Parallel Processor
Date: 1990
Literature:
Peter C. Dibble; Michael L. Scott and Carla Schlatter Ellis: "Bridge: A High-Performance File System for Parallel Processors". San Jose, CA 1988 IEEE Computer Society, 8th International Conference on Distributed Computing Systems, June 1988, pp.154-161
FTP: cayuga.cs.rochester.edu
David K. Gillford, Roger M. Needham, J. Donahue and Michael D. Schroeder
The Cedar File System is a part of the Cedar Parallel Programming System. It is a workstation file system that provides access to both a workstation's local disk and to remote file servers via a single hierarchical name space. Cedar is designed to support group programming in the context of a collection of personal workstations, each with a local disk. Workstations are connected to shared file servers by a local area network, and all shared information is kept at the file server computers. CFS differs from previous distributed file systems by changing the semantics of the traditional interface to reflect the intended use.
Model: client/server, loosely coupled
Properties: lightweight processes
Transparency: access, replication, concurrency, location, failure
Running on: Dorado
Date: 1983-1987
Literature:
David K. Gifford, Roger M. Needham and Michael D. Schroeder: "The Cedar File System". Communications of the ACM Vol. 31, No. 3, pp. 288-298, March 1988.
Teitelman W.: "A Tour through Cedar". IEEE Software 1,2 (Apr. 1984), pp. 25-34
D. Swinehart, P. Zellweger and R. Hagmann: "The Structure of Cedar". SIGPLAN Notices, 20(7), pp. 230-244.
Mahadev Satyanarayanan
The Coda file system, a descendant of AFS-2, is substantially more resilient to server and network failures. The ideal that Coda strives for is constant data availability, allowing a user to continue working regardless of failures elsewhere in the system. Coda provides users with the benefit of shared data repository but allows them to rely entirely on local resources when that repository is partially or totally inaccessible. Coda is built on top of Camelot.
Model: client/server
Properties: fault-tolerant, UNIX-compatible
Transparency: location, access, replication, failure
Running on: IBM RT, DECstation 3100 and 5000, IBM 386
Date: 1990
Literature:
M. Satyanarayanan, J. J. Kistler and E. H. Siegel: "Coda: A Resilient Distributed File System". Cambridge, MA 1987 IEEE Computer Society Technical Committee on Operating Systems, Proceedings of the Workshop on Workstation Operating Systems, 5-6, November 1987
M. Satyanarayanan, James J. Kistler, Puneet Kumar, Maria E. Olaski, Ellen H. Siegel and David C. Steere: "Coda: A Highly Available File System for a Distributed Workstation Environment". IEEE Transactions on Computers, Vol. 39, No. 4, pp. 447-459, April 1990.
Alexander Siegel, Kenneth P. Birman and Keith Marzullo
Deceit is an NFS-compatible file system, that was explicitly designed for exploring a wide range of file system semantics and performance. Design decisions that locked file semantics were delayed as long as possible. Whenever feasible, variable parameters were used instead of constants. These parameters control the behavior of each protocol and the interaction between protocols. Deceit is build from several different control protocols, and each protocol addresses a different aspect of file system behavior. The Deceit server program can be coursely devided into three components. The first component is a name service. The second component is a segment service. It provides bulk data storage and replication. On top of both services is a full NFS file service which uses the other two components for storage and communication, called the NFS envelope.
Model: server/client
Properties: UNIX-compatible, message passing
Transparency: location, access, replication, failure, concurrency
Running on: Sun-4
Date: 1989 - 1991
Literature:
Alex Siegel, Kenneth Birman and Keith Marzullo: "Deceit: A Flexible Distributed File System", Department of Computer Science at Cornell University", November 1989, TR 89-1042, Ithaca, NY.
Alex Siegel, Kenneth Birman and Keith Marzullo: "Deceit: A Flexible Distributed File System", In Summer 1990 USENIX Conference, pp. 51-61, Anaheim, CA, June 1990, USENIX Association.
FTP: ftp.cs.cornell.edu cu-arpa.cs.cornell.edu
H. Sturgles, J. Mitchell and J. Israel
The distributed file system (DFS) is implemented to provide a transparent file handling mechanism so that any authorized user can access any file in the network by simply mentioning the name without knowing the physical location. To retrieve data the user submits a query which the DFS broadcasts to all the nodes where the query is executed. The results are then transmitted back to the originating node, where they are compiled and displayed to the user. The DFS is designed after considering the various requirements and specifications peculiar to the defence environment. In view of the hierarchic organizational structure of the defence services, a distributed data storage system was envisaged in which skeleton files with the same record structure are automatically generated at all available lateral nodes, whenever the new file is created at any node, i.e. the data is partitioned horizontally. The distributed file system described differs from existing file servers, namely Cambridge File Server, Felix File Server, Sanchay, etc., in the important aspect that whereas all the above systems provide primitive facilities at the file and page level, the presented system provides additional facilities for automatic update of files after validation and a network transparent query facility.
Model: server/client
Properties: atomic transactions
Transparency: access, location, replication
Running on:
Date: 1980
Literature:
H. Sturgles, J. Mitchell and J. Israel: "Issues in the Design and Use of Distributed File System". ACM Operating Systems Review, July 1980.
A. Jain, H. N. Mahabala, K. B. Lakshmanan and S. Srinivasan: "A distributed file system with query processing facility over PRIMENET". Madras, India 19-2 Comput. Soc. India, IFIP, UNESCO, NETWORKS India 84. International Symposium on Data Communication and Computer Networks, 19-21 Oct. 1984, pp.196-197, 6 REFS. Treatment PRACTICAL.
Andy Hisgen, Andrew Birrell, Jerian Chuck, Timothy Mann, Michael Schroeder and Garret Swart
Echo is a distributed file system being designed and built at DEC SRC, with the primary goals of exploring issues of scaling and performance. Echo provides a global, hierarchical name space, for scaling and for uniformity of access. Replication is employed for availablity. Performance is archieved by caching on clients, and by using a log on the file server to reduce disk seeks. In the Echo distributed file system two different replication techniques are employed, one at the upper level of the hierarchical name space, the naming service, and another at the lower levels of the name space, the file volume service.
Model: workstation, homogeneous
Properties: UNIX-compatible, replication, traditional hierarchical naming, global
naming
Transparency: replication, location
Running on: DEC Workstations
Date: 01.01.89 - ?
Literature:
Andy Hisgen, Andrew Birrell, Jerian Chuck, Timothy Mann, Michael Schroeder and Garret Swart; "Granularity and Semantic Level of Replication in the Echo Distributed System". IEEE Computer Society Technical Committee on Operating Systems and Application Environments Newsletter, pp. 30-32, 1990.
Andy Hisgen, et al.: "Availability and Consistency Trade-Offs in the Echo Distributed File System.", Proceedings of the Second IEEE Workshop on Workstation Operating Systems, CS Press, Los Alamitos, Calif., Order No. 2003, Sept. 1989.
Gerald J. Popek, Richard G. Guy, Thomas W. Page, Jr. and John S. Heidemann
Ficus is a replicated general filing environment for Unix intended to scale to very large networks. The system employs an optimistic "one copy availability" model in which conflicting updates to the file system's directory information are automatically reconciled, while conflicting file updates are reliably detected and reported. The system architecture is based on a stackable layers methodology which permits a high degree of modularity and extensibility of file system services.
Model: loosely coupled
Properties: UNIX-compatible, WAN support, atomic transactions
Transparency: location, access, replication, migration, failure
Running on: Sun-4
Date: 1990
Literature:
Thomas W. Page, Gerald J. Popek, Richard G. Guy and John S. Heidemann: "The Ficus Distributed File System" Replication via Stackable Layers, Los Angeles, CA (USA), April 1990
Gerald Popek, Richard Guy, Thomas Page Jr. and John Heidemann: "Replication in Ficus Distributed File Systems", The Workshop on Management of Replicated Data, Houston, TX, IEEE, pp. 5--10, November 1990, Also in Technical Committee on Operating Systems and Application Environments Newsletter 4(3), Fall 1990.
Richard Guy, John Heidemann, Wai Mak, Thomas Page Jr. and Gerald Popek: "Implementation of the Ficus Replicated File System", Summer 1990 USENIX Conference, Anaheim, CA, USENIX Association, pp. 63-71, June 1990.
FTP: ftp.cs.ucla.edu /pub/Ficus
M. Fridrich and W. Older
Helix is a distributed file system developed as part of a distributed OS, called XMS. With abstraction layering and system decomposition, all the user sees is one homogeneous system. Helix combines capability-based access with a user organized directory structure to uniformly access objects distributed over a Local Area Network. Security and system integrity are further enhanced by atomic actions that can be performed on an object or a set of objects. The architecture of Hermix is described in terms of an abstraction layering and system decomposition over a Local Area Network. Helix provides an appearance of uniformity to its clients yet it accommodates a diversity of autonomous devices. Behind the scene, the architecture is supporting 15 LANs and close to 1000 workstations. The Felix File Server is a part of the system.
Model: loosely coupled, server/client, integrated
Properties: object-oriented, atomic transactions
Transparency: access, location
Running on:
Date: 1983
Literature:
M. Fridrich and W. Older: "Helix: The Architecture of a Distributed File System". IEEE, Proceedings of the 4th International Conference on Distributed Computing Systems, New York, 1984, pp. 422-431.
Fridrich, M. and Older, W: "Helix: the architecture of the XMS distributed file system". IEEE Software, 2(3), pp. 21-29, May 1985
M. Fridrich and W. Older: "The Felix File Server". ACM SIGOPS, Proc. of the 8th Symposium on Operating System Principles, Dec. 1981, pp. 37-44.
C.H. Sauer, Don W. Johnson, Larry K. Loucks, Amal A. Shaheen-Gouda and Todd A. Smith
RT PC Distributed Services provides distributed operating system capabilities for the AIX operating system. These include distributed files with local/remote transparency, a form of "single system image" and a distributed interprocess communication. Applications, including data management/data base applications, can typically be used in the distributed environment without modification to existing object code. Distributed Services is architected for strong compatibility with AIX, the UNIX operating system, IBM architectures such as SNA and some of the architecture of Sun Microsystems NFS. The Distributed Services implementation includes caching mechanisms and other algorithms designed for high performance without sacrificing strict functional transparency.
Model: loosely-coupled workstations
Properties: UNIX-compatible
Transparency: location, access
Running on: IBM AIX Workstations
Date: 1987
Literature:
C.H. Sauer, Don W. Johnson, Larry K. Loucks, Amal A. Shaheen-Gouda and Todd A. Smith.: "RT PC Distributed Services Overview," ACM Operating Systems Review, Vol. 21, No. 3, July 1987, pp. 18-29.
M. Satyanarayanan, John H. Howard, David A. Nicols, Robert N. Sidebotham and Alfred Z. Spector
ITC is a distributed file system, developed for the Vice/Virtue Network at CMU. From the point of view of each workstation, the space of file names is partitioned into a local name space and a shared name space. The shared name space is the same for all workstations, and contains the majority of files accessed by users. The local name space is small, distinct for each workstation, and contains files which typically belong to one of the following classes: system files, temporary files, sensitive data files, and a small number of frequently used files. Caching is the main form of replication in ITC. Virtue caches entire files along with their status and custodianship information.
Model: client/server
Properties: UNIX-compatible, sophisticated caching
Transparency: replication, location, access
Running on: Sun-3, Virtue workstation
Date: 1985
Literature:
M. Satyanarayanan, John H. Howard, David A. Nicols, Robert N. Sidebotham, Alfred Z. Spector and Michael J. West; "The ITC Distributed File System: Principles and Design". Proceedings of the 10th ACM Symposium on Distributed Systems Principles 19(5), pp. 35-50, December 1985.
Herman Chung-Hwa Rao and Larry L. Peterson
Jade is an internet file system that provides an uniform way to name and access files in an internet environment. The main emphasis in this work has been on issues of scalability. More precisely, we recognize four characteristics of scalability: size, wide area, autonomy, and heterogeneity. Owing to size and wide area, techniques such as broadcasting, central control, and central resources, which are widely adopted by local area network file systems, are not adequate for an internet file system. An internet file system must also support the notion of autonomy because an internet is made up by a collection of autonomous organizations. Finally, heterogeneity is the nature of an internet file system not only because of its size, but also because of the autonomy of the organizations in an internet. Jade is a logical system that integrates a heterogeneous collection of existing file systems. It does not provide any storage of its own; it only maps file names onto files that are stored in existing file systems. These underlying file systems may be heterogeneous in the, sense that they support different file access protocols for communications between file servers and their users. The access protocol not only provides the key to access file systems, but also hides the heterogeneity of the operating systems and the architectures, of the hosts where file systems are located. Because of autonomy, Jade is designed under the restriction that the underlying file systems may not be modified in software nor changed in administration. The underlying file systems treat an instance of the Jade File System as a regular file system user without any special privileges. Rather than providing a global name space, Jade permits each user to define a private name space. A given user has the same view of heterogeneous, internet-wide file systems, regardless of what machine he or she is using. In other words, Jade is partitioned into a collection of per-user, autonomous, logical file systems, each of which consists of a set of physical file systems and a dedicated logical name space. With the per-user approach, Jade fully decentralizes the construction and maintenance of name spaces from, system administrators to individual users. To facilitate file sharing, Jade allows one logical file system to be mounted into another Jade file system, in the same way that a physical file system can be mounted into a Jade file system. This allows each user to transparently name and access files through another user's name space. To support a variety of access paradigms and to encourage collaboration among users, Jade refines the mount operation provided by Unix-like file systems to allow multiple file systems, either logical or physical, to be mounted under a single directory. This feature is called the multiple mount. With the multiple mount,, users are able to group files from different file systems under one directory and transparently locate files replicated on several file systems. Moreover, a set of users are able to share a collection of files stored on different file systems without worrying about interference from one another. Jade employs whole file caching. Opening a file causes it to be cached in its entirety, on some nearby disk. Reads and writes are directed to the cached copy without involving the original servers. The valid cached copy can be used for further opens as well. Because, of the high cost of accessing remote servers, complete file caching is needed to reduce the network traffic; it is essential for good performance in the internet. A prototype of Jade has been implemented to examine and validate its design. The prototype consists interfaces to the Unix File System, the Sun Network File System, and the File Transfer Protocol. We are currently working on the implementation of the interface to the Andrew File System.
Model: loosely coupled, client/server
Properties: UNIX-compatible, WAN support
Transparency: location, access
Running on: Sun-4, Sun OS 4.1
Date: 1989-1991
Literature:
Herman C. Rao and Larry Peterson: "Accessing Files in an Internet: The Jade File System", Department of Computer Science, University of Arizona, 1991, pp. 90-30
Rao, C. Herman: "The Jade File System", Ph.D. Diss., Department of Computer Science, University of Arizona", August 1991.
L. G. Reid and P.C. Karlton
Mesa is a distributed file system that views processes as cooperative and allows therefore to support a more sophisticated sharing of files among independent processes. If one process wishes to use a file in a way that conflicts with the way that a second process is using the file, the process that is using the file may be asked to relinquish it. The Mesa file system facilitates inter-process cooperation by asking clients to provide procedures that the file system can call to ask the client to give up a file or tell the client that a file is available.
Model: loosely-coupled
Properties: sophisticated locking mechanism
Transparency: location, access, concurrency
Running on: Xerox Workstation and Pilot OS
Date: 1982
Literature:
L. G. Reid and P.C. Karlton: "A File System Supporting Cooperation between Programs". ACM Proc. of the 9th Symposium on Operating System Principles, October 1983.
D. R. Brownbridge, L.F. Marshall, B. Randell and C. Snow
Newcastle Connection was an early attempt to build distributed file system on top of Unix and extending the file system hierarchy across the machines.
Model: multiple-instance, workstations, loosely-coupled
Properties: UNIX-compatible, crash recovery, RPC
Transparency: access, location
Running on: UNIX-Workstatons
Date: 01.01.80 - 01.01.82
Literature
D. R. Brownbridge, L.F. Marshall and B. Randell: "The Newcastle Connection, or UNIXes for the world unite!", Software Practice and Experience 12, pp. 1147-1162, July 1982.
B. Clifford Neuman,
Prospero is a distributed file system which supports a user centered view of files scattered across the Internet and is based on the Virtual System Model. Prospero supports user centered naming: users construct their own view of the files that are accessible. The mapping from names to files is controlled by this view. Objects may be organized in multiple ways and the same object may appear in different virtual systems or even with multiple names in the same virtual system.
Model: fully integrated, kernelized/micro kernel, object-oriented
Properties: UNIX-compatible, synchronization, migration, channels
Transparency: location, access
Running on: UNIX-Workstations
Date: 01.01.1991
Literature
B. Clifford Neuman: "The Virtual System Model for Large Distributed Operating Systems", University of Washington, Seattle, WA (USA), April 1989.
B.Clifford Neumann: "The Prospero File System User's Manual", National Science Foundation (Grants No. DCR-8420945 and CCR-8611390, US WEST advanced Technologies, and Digital Equipment Coporation.
Luis Felipe Cabrera and Jim Wyllie
The basic idea behind recovery management in Quicksilver:
Clients and servers interact using a message-passing interprocess communication. Properly written programs should be resilient to external process and machine failures, and should be able to recover all resources accoiated with failed entities. Servers use the commit protocol messages as a signalling mechanism to inform them of failures, and as a synchronisation mechanism for archiving atomicity.
Model: client/server, kernelized
Properties: crash recovery, stable storage, atomic transactions, synchronization,
RPC, message-passing
Transparency: access, location, failure
Running on: IBM RT, IBM 370, RS/6000
Date: 1987
Literature
Roger Haskin, Yoni Malachi, Wayne Sawdon, and Gregory Chan: "Recovery Management in QuickSilver", ACM Transactions on Computer Systems, pp 82-108, February 1988.
Luis Felipe Cabrera and Jim Wyllie: "QuickSilver Distributed File Services: An Architecture for Horizontal Growth". San Jose, CA (USA), April 1987.
M. Theimer, L.-F. Cabrera,and J. Wyllie: "QuickSilver Support for Access to Data in Large, Geographically Dispersed Systems", Newport Beach, CA USA, IEEE, pp. 28-35, June 1989.
L. F. Cabrera, M. Goodfellow, R. Haskin, M. Theimer, and J. Wyllie: "QuickSilver Distributed System". Cambridge, MA 1987 IEEE Computer Society Technical Committee on Operating Systems, Proceedings: Workshop on Workstation Operating Systems, 5-6, November 1987.
Andrew P. Rifkin, Michael P. Forbes, Richard L. Hamilton, Michael Sabrio, Suryakanta Shah, and Kang Yueh
RFS adds a new dimension to the user computing environment by providing transparent access to remote files. RFS allows access of all file types, including special devices and named pipes, in addition to allowing file and record locking on remote files. The main goal of RFS is to provide users and applications a means of accessing remote files.
Model: client/server, fully integrated
Properties: UNIX-compatible, pipes or streams, crash recovery, synchronization
Transparency: access, location
Running on: Unix System V
Date: 1986-?
Literature
Andrew P. Rifkin, et. al.: "RFS Architectural Overview", USENIX Summer Conference Proceedings, Atlanta, Georgia, 1986, pp. 248-259.
A.P.Rifin, M.P. Forbes, R.L.Hamilton, M.Sabrio, S. Shah, and K. Yueh: "RFS Architectural Overview", AT&T 190 Riover Road, Summit, NJ 07901.
C. S. Ellis and R. A. Floyd
Roe is a networkwide file system being developed for a heterogeneous local network. The system has been designed for two purposes: to serve as a testbed for experimenting with various policies for file migration and distribution strategies and to provide users with a logically coherent file system that takes advantage of distributed and diverse resources. The system is a synthesis of solutions to the problems of ensuring consistency of replicated data, allowing transparent reconfiguration, and providing adequate file accessibility. Mechanisms are provided that allow migration, replication of file objects, and replication of access information to work together.
Model: workstation, minicomputer, heterogeneous, client/server,
loosely-coupled, monolithic
Properties: datagram, standard protocols, replication, synchronization, atomic
transactions, identity based, heavyweight, traditional hierarchical
global naming, asynchronous message passing
Transparency: replication, location, access, migration
Running on: Xerox Alto personal computer, VAXes
Date: 01.01.83 - ?
Literature:
C. S. Ellis; R. A. Floyd: "The ROE File System". Clearwater Beach, FL, USA 19 O IEEE Comput. Soc. Press, ISBN: 0-8186-0501-4 Silver Spring, MD, USA, p: viii+195, Proceedings Third Symposium on Reliability in Distributed Software and Database Systems, pp.175-181, 23 REFS Treatment PRACTICAL, 17-19 Oct. 1983.
David.P. Reed and Liba Svobodova
Swallow is an experimental project that tested flexibility of several advanced ideas on the design of object-riented distributed systems. Its purpose was to provide a reliable, secure and efficient storage in a distributed environment consisting of many personal machines and one or more shared data storage servers. Swallow implements a uniform interface to all objects accessible from a personal computer.
Model: client/server, workstation, object-oriented, loosely-coupled
Properties: process migration, crash recovery, stable storage,
synchronization, atomic transactions, replication, encryption, migration
Transparency: access, replication, concurrency, location
Running on:
Date: 1980 - ?
Literature
Gail C. Arens: "Recovery of the Swallow Repository", MIT Laboratory for Computer Science, Technical Report 252, January 1981 (MS Thesis), 120 pp.
D.P. Read and L. Svobodova: "SWALLOW: A Distributed Data Storage system for a Local Network". Proceedings of the International Workshop on Local Networks, Zurich, Schwitzerland, August 1980.
L. Svobodova: "File Servers for Network-Based Distributed Systems". IBM Tech. Report RZ1186, (nov 2, 1982) IBM Zurich Research Lab, 8803 Rueschlikon, Switzerland.
Liba Svobodova: "Management of Object Histories in the Swallow Repository", MIT Laboratory for Computer Science, Technical Report 243, July 1980.
Mahadev Satyanarayanan, Ed Zayas
VICE/Virtue/Venus was the first phase of development of the Andrew File System, originally at the ITC. It has gone through several major revisions, and parts of it are incorporated in AFS3 product (which isn't really an acronym for Andrew File System, it's just a three-letter pseudo-acronym, which was chosen so as not to confuse people too terribly much). The DFS included in the OSF DCE is a major revision of AFS3.
Model: client/server, loosely-coupled
Properties:
Transparency: location, migration
Running on: UNIX-Workstations
Date: 1984-
Literature
Mahadev Satyanarayanan: "Scalable, Secure, and Highly Available Distributed File Access", IEEE Computer, May 1990, pp. 9-21.
D. Swinehart, G. McDaniel and D. Boggs
WFS is a simple shared file server available to a large network community. WFS responds to a carefully limited repertoire of commands that client programs transmit over the network. The system does not utilize connections, but instead behaves like a remote disk and reacts to page-level requests. The design emphasizes reliance upon client programs to implement the traditional facilities (stream io, a directory system, etc.) of a file system. The use of atomic commands and connectionless protocols nearly eliminates the need for WFS to maintain transitory state information from request to request. Various uses of the system are discussed and extensions are proposed to provide security and protection without violating the design principles.
Model: client/server
Properties: atomic transactions
Transparency: location, access
Running on:
Date: 1979
Literature:
Swinehart D., McDaniel G. and Boggs D.: "WFS: A simple shared file system for a distributed environment." In Proceedings of the 7th Symposium on Operating Systems Principles, ACM, New York, 1979, pp. 105-114
Daniel Swinehart, Gene McDanie and David Boggs: "WFS: A Simple File System for a Distributed Environment". Pacific Grove, CA, USA 1979 Xerox Palo Alto Research Center, Palo Alto, CA, USA, ACM, New York, USA ix+163 pp, isbn 0-89791-009-5, Proceedings of the 7th Symposium on Operating Systems Principles, December 1979, pp. 9-17.
A. D. Birrel, B.J. Nelson and D.R. Boggs
The XDFS was intended to provide a basis for database research. An XDFS transaction can cover updates to a number of files so that the atomicity of a higher level database operation can be maintained. In a database environment, a few highly interrelated and often large files may be accessed concurrently by a number of clients. To reduce the degree of serialization, the XDFS provides fine-gained locking at the byte level. One of the main design goals of the XDFS was to allow a flexible allocation of computing and storage resources to the file service. For each local network, the choice of the number of server processes and the amount of disk storage given to each server can be made by matching desired performance and cost. The glue which is used to assemble the different servers into a single file service is the atomic transaction mechanism which is designed to allow several servers to change files in a single atomic update.
Model: workstation, homogeneous
Properties: datagram, crash recovery, stable storage, synchronization,
atomic transactions, identity based
Transparency: location, access, concurrency, failure
Running on: Alto minicomputer
Date: 01.01.81 - ?
Literature:
James G. Mitchell: "A Comparison of Two Network Based File Servers (Summary) Proceedings of the 8th Symposium on Operating Systems, Communications of the ACM, Vol. 25, No. 4, April 1982, pp. 233-245.
Xerox Corporation: "Xerox Network Systems Architecture". Stamford, Connecticut 1985 Xerox Corporation, Office Systems Division, XNSG 068504, April 1985.
Eric E. Johnson
ARGOS is a distributed message-based operating system for studying the ramifications of the Virtual Port Memory Architecture (VPM). In the VPM architecture individual processing elements reference a global memory using system-wide virtual addresses translated at the memory. There is a separate message bus used for all interprocessor messages. The processing elements have large caches with no coherency support. ARGUS provides each process a private process space, performing message-based communication and synchronization via messages. ARGOS uses the global memory to implement rapid message passing and copy-on-write between processes. The object manager, file manager, and pager all utilize the global memory for rapid communication and the message bus for the synchronization.
Model: Global Memory Message Passing Multiprocessor, shared memory
Properties: message passing, UNIX-compatible, real-time support
Transparency:
Running on: VMP machine consisting of MC 68020 processors
Date: 1989
Literature:
Eric E. Johnson: "Argos - a research gmmp operating system: Overview and interfaces". Tech. Report NMSU-ECE-89-007A, New Mexico State University, Aug. 1989.
FTP: ftp.cse.ucsc.edu /pub/tcos
Roy Campbell, Garry Johnston, Vincent Russo and P. W. Madany
Choises, a Class Hierarchical Open Interface for Custom Embedded Systems, provides a foundation upon which to construct sophisticated scientific and experimental software. Unlike more conventional operating systems, Choises is intended to exploit very large multi-processors interconnected by shared memory or high-speed networks. Uses include applications where high-performance is essential like data reduction or real-time control. It provides a set of software classes that may be used to build specialized software components for particular applications. Choises uses a class hierarchy and inheritance to represent the notion of a family of operating systems and to allow the proper abstraction for deriving and building new instances of a Choises system. At this basis of the class hierarchy are multiprocessing and communication objects that unite diverse specified instances of the operating system in particular computing environments.
Model: multiprocessor, shared memory
Properties: object-oriented, real-time support, UNIX-compatible
Transparency: location, access
Running on: Encore Multimax, Intel iPSC/2 hypercube
Date: 1989
Literature:
R. H. Campbell and P. W. Madany: "Considerations of Persistence and Security in Choices, an Object-Oriented Operating System". Bremen (Federal Republic of Germany), May 1990
FTP: choices.cs.uiuc.edu /Papers
Michael D. Schroeder and Michael Burrows
The Firefly system kernel, called the Nub, implements a scheduler, a virtual memory manager, and device drivers. The Nub executes in VAX kernel mode. The virtual memory manager provides multiple user addresses for application programs, one of which contains the rest of the operating system. The scheduler provides multiple threads per address space, so that the Nub, operating system, and application programs can be written as true concurrent programs that execute simultaneously on multiple processors. The system is structured to operate best on multiple processors.
Model: shared memory, multiprocessor
Properties: lightweight processes
Transparency:
Running on: Firefly multiprocessor on MicroVAX-II
Date: 1990
Literature:
Michael D. Schroeder and Michael Burrows: "Performance of Firefly RPC". ACM Transactions on Computer Systems, Vol. 8, No. 1, February 1990, pp. 1-17.
Charles P. Thacker and Lawrence C. Stewart: "Firefly: a Multiprocessor Workstation". Palo Alto, CA 1987 DEC SRC, ACM, Proceedings Second International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS II), Computer Architecture News, Vol. 15, No.5, Operating Systems Review, Vol. 21, No.4, SIGPLAN Notices, Vol. 22, No.10, October 1987, pp.164-172.
John K. Ousterhout, Donald A. Scelza, Pradeep S. Sindhu and D. D. Redell
Medusa is an early distributed multi-user multiprocessor operating system implemented on the Cm* multiprocessor. Medusa is the second operating system for Cm*. The first system, StarOS, has been concerned with making Cm* programmable at a high level by users. The functional control structure in Medusa is a task force, defined to be a collection of activities that cooperate closely in the execution of a single logical task. In general the activities of a task force run concurrently on different processors. All programs, including the operating system utilities, are task forces. Medusa is made up of three pieces, the Kmap microcode of the communication controller, a replicated kernel, and distributed utilities. The bulk of the operating system is distributed between five utility task forces, a memory manager, a file system, a task force manager, an exception reporter, and a debugger.
Model: multiprocessor
Properties: object-oriented, message passing
Transparency: location, access
Running on: CM* multiprocessor
Date: 1979
Literature:
Ousterhout, J. K: "Partitioning and cooperation in a distributed multiprocessor operating system: MEDUSA". Report, Department of Computer Science, Carnegie-Mellon University.
Ousterhout, J. K., Scelza, D. A. and Redell, D. D: "MEDUSA: An experiment in distributed operating system structure". Communications of the ACM, 23(2), pp. 92-104.
John K. Ousterhout: "Medusa: A Distributed Operating System". Dept. of Computer Science, Carnegie-Mellon University, Pittsburgh, PA, UMI Research Press, Call number QA76.6 Q92, 1981.
Schroeder Wolfgang
PEACE is the distributed operating system for a MIMD Message Passing Architecture, the SUPRENUM multiprocessor. PEASE differs from presently available distributed operating systems, such as MACH and CHORUS, in that it was primarily designed to support the execution of distributed MIMD programs on largely parallel computer systems. The guideline was to make these programs work, rather than to implement another distributed operating system. Strongly influenced by the MOOSE project, PEACE is process-structured and message-based. Extending fundamental MOOSE ideas, it is distributed and supports the implementation of networked system services provided by a large set of arbitrarily distributed system processes.
Model: client/server, MIMD multiprocessor, single-instance DOS
Properties: message passing, lightweight processes, UNIX-compatible, fault-tolerant,
process migration
Transparency: location, access, failure
Running on: SUPRENUM MC68020
Date: 1988
Literature:
Wolfgang Schröder: "PEACE: The distributed SUPRENUM operating system". Parallel Computing, Vol. 7, No. 3, pp. 325-333, September 1988.
Wolfgang Schröder: "PEACE: A Distributed Operating System for an MIMD Message-Passing Architecture". St. Petersberg, FL Third International Conference on Supercomputing (ICS '88), Proceeding Supercomputing '88: Technology Assessment, Industrial Supercomputer Outlooks, European Supercomputing Accomplishments, and Performance & Computations, Vol. 2, pp. 302-312.
Georg Schaffler: "Connecting PEACE to UNIX". Parallel Computing, Vol. 7, No.3, September 1988, pp. 335-339.
Michael L. Scott, Thomas J. LeBlanc, Brian D. Marsh, Timothy G. Becker, Cezary Dubnicki,
and Markatos
Psyche is a multiprocessor operating system designed to facilitate multi model parallel programming-the simultaneous use of many different styles of paralism, both across programs and within a single program. Psyche presents an user interface in which processes, communication, sharing, and protection are managed by user level codes.
Model: multi-processor, kernelized/micro kernel, shared memory
Properties: replication, RPC, Shared Data Structures, protection
Transparency: access, location
Running on: BBN Butterfly, GP 1000
Date:
Literature
Michael L Scott, Thomas J. LeBlanc, Brian D. Marsh, Timothy G. Becker, Cezary Dubnicki , and Markatos: "Implementation Issues for the Psyche Multiprocessor Operating System. Implementation Issues for the Psyche Multiprocessor Operating System". Computing Systems, pp. 101-137, 1990.
Michael L. Scott , Thomas J. LeBlanc, and Brian D. Marsh: "Implementation Issues for the Psyche Multiprocessor Operating System". Ft. Lauderdale, FL 1989 University of Rochester, Usenix Association, Workshop on Experiences with Distributed and Multiprocessor Systems (WEBDMS), October 1989, pp.227-236.
Le Blanc, Scott, Marsh, Markatos, Dubnicki, Crovella, and Becker: "The Psyche Parallel Operating System", Computer Science Department, University of Rochester, NY 14627-0226.
FTP: cayuga.cs.rochester.edu/pub/systems_papers
Pul Austin, Kevin A. Murray and Andy Wellings
The Wisdom project is an ongoing research project into distributed and parallel operating systems at the University of York (England). Development of the Wisdom project followed the decision to explore the potential of a computing engine based on a point-to-point network of single-processor timesharing systems and a local-area networks of personal workstations. The Wisdom nucleus is a kernel that provides the foundation for a parallel scalable system. The nucleus is composed of four components: a routing module, a tasking module, a load-balancing module and a naming module. Every Transputer runs the nucleus. Although the Wisdom nucleus occupies the role taken by a kernel in most operating systems, it is intended to conform to the open model i.e. any of the four modules may be replaced if the standard ones are not suitable. The routing module is responsible for transporting messages between user tasks on the same or different processors. The task module creates and manages the virtual processors that run on its real processor. The load-balancing module has the job of deciding on which processor to execute a new task. The namers supply a mechanism to allow tasks to open communication channels with other tasks with which they have no current connection.
Model: multiprocessor
Properties: load-balancing, message passing, micro kernel
Transparency: location, access, replication
Running on: INMOS T4 Transputer
Date: 1988
Literature:
Pul Austin, Kevin Murray and Andy Wellings: "The Design of an Operating System for a Scalable Parallel Computer Engine". Software-Practice and Experience, Vol. 21(10), October 1991, pp. 989-1013.
Kevin A. Murray and Andy Wellings: "Wisdom: A distributed operating system for Transputers". Computer Science and Engineering, 5(1), pp. 13-20, 1990.
Yolande Berbers, Wouter Joosen, Herman Moons and Pierre Verbaeten
XENOOPS is an eXecution ENvironment for Object-Oriented Parallel Software. It supports parallel applications designed according to an object-oriented approach. XENOOPS focuses on parallel computing systems with distributed memory. It offers basic mechanisms for a variety of object models; furthermore, it supports grouping of objects, and object splitting and joining. XENOOPS offers dynamic load balancing, using a transparent migration facility. XENOOPS itself has an object-oriented architecture, which gives application writers the possibility to customize the environment to their application's needs. A prototype implementation has been built on a transputer system on top of the Helios operating system.
Model: multiprocessor
Properties: process migration, object-oriented, load-balancing
Transparency: access, location, performance, migration
Running on: T800 Transputer system
Date: 1991
Literature:
Yolande Berbers, Wouter Joosen, Herman Moons and Pierre Verbaeten: "An Environment for Object-Oriented Parallel Applications: the XENOOPS Approach", Fourth ISMM International Conference Parallel and Distributed Computing and Systems, October 8-11, 1991, Washington, D.C. USA.
Yolande Berbers, Wouter Joosen, Herman Moons and Pierre Verbaeten: "The XENOOPS project", 1991 International Workshop on object-orientation in operating systems.
XOS is an operating system for the X-Tree Architecture. XOS was developed to investigate the effects of the X-tree architecture on operating system design. Two concepts are of special interest. The first is demand paging across the network of nodes. The second is separation of the global object space and the directory structure used to reference it.
Model: multi-processor, object-oriented
Properties: process migration, shared memory, channels
Transparency:
Running on: X-Tree Architecture
Date: 1981
Literature
B. Miller and D. Presotto: "XOS: An Operating System for the X-TREE Architecture". ACM Operating Systems Review 15(2), pp. 21-23, April 1981.
V.P. Holmes and D.L. Harris
The Hawk operating system kernel was specifically designed and implemented to support real-time applications on the SANDAC V embedded multiprocessor. The kernel provides a tasking model for program decomposition and supports message passing, synchronization, as well as other ancillary services. The kernel primitives have UNIX-like system call interface to the C language and were designed to provide users a choice of level of abstraction, yet perform efficiently and behave predictably.
Model: bus-coupled multiprocessor
Properties: real-time support, message passing, fault-tolerant, UNIX-compatible,
micro kernel
Transparency: location, access, replication
Running on: SANDAC V MC 68020
Date: 1989
Literature:
V.P. Holmes and D.L. Harris: "A Designer's Perspective of the Hawk Multiprocessor Operating System Kernel.", Operating Systems Review, Vol. 23, No. 3, pp. 158-172, 1989.
W. Wulf, E. Cohen, W. Corwin, A. Jones, R. Levin and J.K. Ousterhout
HYDRA is a multiprocessor operating system kernel for an early experimental tightly-coupled distributed operating system. HYDRA introduces a general notion of resource, both physical and virtual, called an object. Mechanisms are presented for dealing with objects, including the creation of new types, specification of new operations applicable to a given type, sharing, and protection of any reference to a given object (capability) against improper application of any of the operations defined with respect to that type of object. The mechanisms provide a coherent basis for extension of the system in two directions: the introduction of new facilities, and the creation of highly secure systems.
Model: shared memory multiprocessor
Properties: object-oriented, fault-tolerant, message passing, capabilities
Transparency: location, access
Running on: Carnegie-Mellon Multi-Mini-Processor, CM*
Date: 1974
Literature:
E. Cohen and D. Jefferson: "Protection in the Hydra operating system". In ACM Proceedings of the 5th Symposium on Operating System Principles 9, 5 (November), pp. 141-160.
William A. Wulf, et. al: "HYDRA: The Kernel of a Multiprocessor Operating System". Communications of the ACM, 17(6), June 1974, pp. 337-345.
F.AA. Vaughan, C.D. Marlin and C.J. Barter
The Leopard kernel is a distributed operating system kernel for a closely-coupled multiprocessor workstation. The strategy adopted was to obtain the distributed V-System from Stanford University and then to develop a kernel to permit this system to run on the Leopard multiprocessor architecture. The differences resolve around the introduction of shared memory. As a result, three levels of kernel can be distinguished: a kernel instance residing in a single processor of a multiprocessor node, a multi-threaded kernel which is distributed over a multiprocessor node and the distributed kernel executing over a loosely-coupled collection of nodes.
Model: closely-coupled multiprocessor, shared memory
Properties: process migration, lightweight processes, message passing, micro kernel
Transparency:
Running on: Leopard four processor system, NS32532
Date: 1983 - 1989
Literature:
F.A. Vaughan, C.D. Marlin and C.J. Barter: "A Distributed Operating System Kernel for a Closely-Coupled Multiprocessor", The Australian Computer Journal, Vol. 20, No. 2, May 1988.
University of North Carolina, USA
Scott Danforth
DOT is a distributed operating system model of a tree-structured multiprocessor. DOT was specially designed for direct and maximal parallel execution of formal functional programming (FFP) languages. The model is represented using tasks and abstract data types in C and running on UNIX. User programs consisting of FFP language symbols are placed in a linear array of cells, the leaves of a binary tree of processors, and segments of this array that contain innermost FFP applications execute system programs in order to perform the required reductions. The system programs are written in LPL, a low-level concurrent programming language used to implement FFP primitives on the architecture.
Model: tree-structured multiprocessor
Properties: UNIX-compatible, message passing
Transparency: location, access, concurrency
Running on:
Date: 1983
Literature:
Scott Danforth: "DOT: a distributed operating system model for a tree-structured multiprocessor". IEEE Proceedings of the 1983 International Conference on Parallel Processing, August 1983, pp.194-201.
Robert D. Gaglianello, and Howard P. Katseff
Meglos provides a user-level programming environment and operating system for a system of interconnected processors. It allows the simultaneous execution of a wide range of applications including real-time control, large-scale computations requiring several processors, and general purpose computing. Multiprocessing Applications are simplified with a simple, yet powerful, mechanism for communications within and between processors. Meglos is a variant of UNIX uses additions to system calls and modifications to existing read/write calls on channels (not streams as in SV.3) for synchronization and communication. There are 12 68000s on a backplane interconnections with 80 MByte/S.
Model: multiprocessor, heterogeneous, client/server, loosely-coupled
multiple-instance, monolithic
Properties: UNIX-compatible, real-time support, virtual memory, point-to-point,
multicast, pipes or streams, synchronization, identity based, encryption,
lightweight processes, preemptive multitasking, traditional hierarchical
naming, channels, rendezvous
Transparency: local, access, location
Running on: MC68000 Multiprocessor, VAX-11/780
Date: 01.01.85 - ?
Literature:
R.D. Gaglianello and H.P. Katseff; "Meglos: An Operating System for a Multiprocessor Environment". IEEE Proceedings of the 5th International Conference on Distributed Computing Systems, May 1985, pp.35-42.
Andy Tanenbaum, Sape Mullender and Robert van Renesse
The Amoeba distributed operating system architecture consists of four principal components: Workstations with window system for providing user access, pool processors for computing, specialized servers such as file servers and directory servers and gateway to other systems. The key idea here is, that the workstations are basically terminals. The computing power lies in the pool processors. Amoeba is an capability based DOS which supports WAN communication by a special indirect, synchron and demand driven RPC design. Amoeba's distributed file system is called FUSS.
Model: heterogeneous, hybrid (client/server, processor pool)
Properties: micro kernel, message passing, object-oriented, WAN support
Transparency: access, concurrency, location, replication, failure
Running on: Sun-3, IBM PC, DECstation
Date: 1984
Literature:
Sape J. Mullender, Guido van Rossum, Andrew S. Tanenbaum, Robert van Renesse and Hans van Staveren: "Amoeba: A Distributed Operating System for the 1990s". IEEE Computer, pp. 44-53, May 1990
Sape. J. Mullender and Andrew. S. Tanenbaum: "The Design of a Capability-Based Distributed Operating System". Computer Journal 29, No. 4, pp. 289-299, March 1986
Andrew S. Tanenbaum, Robbert van Renesse, Hans van Staveren and Sape J. Mullender: "A Retrospective and Evaluation of the Amoeba Distributed Operating System". December 1980
Sape J. Mullender: "The Amoeba Distributed Operating System II". Amsterdam, Centre for Mathematics and Computer Science, CWI Newsletter, No.12, September 1986.
FTP: ftp.cse.ucsc.edu, midgard.ucsc.edu, star.cs.vu.nl
Anita Borg, Jim Baumbach and Sam Glazer
The operating system Auros is a distributed version of Unix. Major goals have been transparency of fault-tolerance and efficient execution in the absence of failure. Ease of use is a high priority goal in the design. In Auros two types of processes are distinguished. User processes communicate (perform all input and output) via message and have no direct access to peripherals. Actual device IO is performed as a result of requests sent to peripheral server processes. Peripheral servers are associated with specific devices which they access via special system calls not available to user processes. They execute only in processing units with peripherals and handle all user requests for real IO.
Model: multiprocessor
Properties: UNIX-compatible, fault-tolerant, message passing
Transparency: location, access, failure
Running on: Auragen 4000
Date: 1983
Literature:
Anita Borg, Jim Baumbach and Sam Glazer: "A Message System Supporting Fault Tolerance", ACM, 1983, 0-89791-115-6/83/010/0090, pp. 90-99
Hermann Härtig, Winfried Kühnhauser, Wolfgang Lux, Hermann Streich and G. Goos
The key objective of the BirliX project is to present an operating system design that integrates extensibility and flexibility as the basic part of its architecture. Distributed environments and their impacts on fault tolerance, performance, and security build the second key objective of the BirliX project. While distributed systems give access to a large number of resources that can be used to promote fault tolerance and performance, security becomes a serious problem. The BirliX kernel paradigm is the data abstraction. The system is basically an abstract data type management system with services to define and instantiate types, to identify instances and to support instance communication. The common behavior of all types - concerning distribution, security and fault tolerance - is defined by the so called primary type and is imported from it whenever a new type is defined. A very natural feature of an abstract data type management system is the functional extensibility and adaption to new requirements by simply defining new abstract data types. Concerning distribution, the abstract data type paradigm provides us with the smallest unit of identification and communication, the abstract data type instance. Application programs on BirliX are sets of interacting abstract data type instances distributed among several nodes in a computer network. Instances are identified and located by a distributed naming and locating service that efficiently maps high level names from a network global structured name space to instances. Instances communicate by remote procedure calls in a client/agent relationship, using the results of the location service to achieve network transparency.
Model: integrated, loosely coupled
Properties: fault-tolerant, atomic transactions
Transparency: access, replication, concurrency, location, failure
Running on: Sun-4
Date: 1989
Literature:
O. C. Kowalski and H. Hartig: "Protection in the BirliX Operating System". Paris, France 1990 IEEE, Proc. 10th International Conference on Distributed Computing Systems, May-June 1990, pp.160-166.
FTP: gmdzi.gmd.de /pub/gmd/BriliX
R. A. Finkel, M. L. Scott, Y. Artsy and H.-Y. Chatlg
Charlotte is a simple distributed operating system and is intended as a testbed for developing techniques and tools to exploit large-grain parallelism in computation-intensive problems. The Charlotte kernel provides a process migration mechanism as well as a method for processes to obtain elaborate state information to aid in decision making. Processes do not share memory and IPC is completely location independent. Communication is non-blocking, but synchronous and is on reliable, symmetric, bidirectional links named by capabilities.
Model: loosely coupled
Properties: process migration, message passing
Transparency: access, replication, location
Running on: Crystal, VAX-11/750
Date: 1983-1989
Literature:
Raphael. A Finkel, Michael L. Scott, Yeshayahu Artsy and Hung-Yang Chang: "Experience with Charlotte: simplicity versus function in a distributed operating system". IEEE Transactions on Software Engineering, Vol. 15, No. 6, June 1989
Raphael Finkel, Marvin Solomon, David DeWitt and Lawrence Landweber: "The Charlotte Distributed Operating System Part IV of the First Report on The Crystal Project". Madison, WA 1983, Univ. of Wis. CS TR 502, October 1983.
M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, J. S. Banino and H. Zimmermann
CHORUS is an architecture for a UNIX-compatible distributed operating system, which follows the actor model of computation, each actor model of consisting of a sequence of processing steps. CHORUS includes a method for designing a distributed application, a structure for its execution and the (operating) system to support this execution. One important characteristic of CHORUS is that the major part of the system is built with the same architecture as applications. In particular, the exchange of messages, which is the fundamental communication/synchronization mechanism, has been extended to the most basic functions of the system. Messages and ports are the other primitives in CHORUS. Fault tolerance is sought by the modularity of actors.
Model: client-server, loosely coupled
Properties: micro kernel, message passing, process migration, object-oriented,
UNIX-compatible, fault-tolerant
Transparency: access, location
Running on: SM90 multi-microprocessor from CNET connected by
Ethernet
Date: 1988
Literature:
M. Rozier, V. Abrossimov, F. Armand, M. Gien, M. Guillemont, F. Hermann and C. Kaiser: "Overview of the Chorus Distributed Operating System". Montigny-le-Bretonneux (France), June 1988
M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann and C. Kaiser: "CHORUS Distributed Operating Systems". CHORUS Distributed Operating Systems, pp. 305-367, 1988
M. Guillemont, P. Ravasio, G. Hopkins, N. Naffah, Calcolo Autom., et al.: "The CHORUS distributed operating system: design and implementation". Florence, Italy 19-2 North-Holland Amsterdam, Netherlands, p: xii +504, ISBN: 0-444-86386-9, Local Computer Networks. Proceedings of the IFIP TC 6 International In-Depth Symposium, pp.207-223, 10 REFS, Treatment PRACTICAL, pp. 19-21, April 1982.
M. Rozier, J. Legatheaux Martins, Yakup Paker, Jean-Pierre Banatre and Muslim Bozyigit: "The CHORUS Distributed Operating System: Some Design Issues". Berlin 1987 Springer-Verlag, Distributed Operating Systems Theory and Practice, Vol. 28, NATO ASI Series F: Computer and Systems Sciences, 1987, pp. 261-288.
FTP: cse.ogi.edu, opera.chorus.fr, ftp.cs.buffalo.edu
M. Litzkow, M. Livny, and M. Mutka
Condor is a distributed operating system, designed to allow network users to take advantage of idle machines. In opposite to other systems with support of process migration, Condor is targeted toward computationally intensive, long running jobs that do not interact with users. Each workstation running Condor has a local scheduler and a background job queue. Further more there is a central coordinator that checks the network for idle workstations every two minutes and distributes the waiting background jobs to the idle ones.
Model: client/server
Properties: process migration
Transparency: access, location, migration
Running on: VAXstation II
Date: 1988
Literature:
M. Litzkow, M. Livny, and M. Mutka: "Condor-A Hunter of Idle Workstations". IEEE, Proceedings of the 8th International Conference on Distributed Systems, June 1988
FTP: shorty.cs.wisc.edu
Rong Chang
Cygnus is a "client/service" model, in which the notion of "service" is a first-class concept. (In the client/server model, that notion is a second-class concept). Cygnus provides a service acquisition mechanism that gives client a uniform system view of server functions. A language veneer over the C programming language is also developed to demonstrate how this mechanism can be supported well through high-level language constructs. Three dramatically different applications have also been built to demonstrate the superiority of this approach. In short, this work suggests that the client/service model provides a better paradigm for structuring distributed applications than the client/server model does.
Model: workstation, client/server, heterogenous
Properties: asynchronous message passing, reliable, language support
Transparency: failure, access
Running on: Sun-4
Date: 1990 - ?
Literature
A. Rong Chang: "A Network Service Acquisition Mechanism for the Client/Service Model", Ph.D. Thesis, Department of Electrical Engineering and Computer Science, University of Michigan, 1990.
Rong Chang, and Chinya Ravishankar: "A Service Acquisition Mechanism for the Client/Service Model in Cygnus", Proc. of the 11th International Conference on Distributed Computing Systems, May 1991, pp. 90-97.
Rong Chang and Chinya Ravishankar: "A Service Acquisition Mechanism for Server-Based Heterogeneous Distributed Systems", Technical Memorandum TM-ARH-020120, Bellcore, 1991, Submitted to IEEE Transactions on Parallel and Distributed Systems.
Rong Chang and Chinya Ravishankar: "A Service Acquisition for the Client/Service Model in Cygnus", IEEE Computer Society Press, Proceedings of the 11th International Conference on Distributed Computing Systems, Arlington, Texas, USA, May 20-24, 1991, pp. 90-97.
Paulo Verisimo, Yves Deswarte, David Powell and Jean-Claude Laprie
The Delta-4 project was initiated to extend the application of the ISO/OSI model to enable open, dependable, real-time systems to be built from off-the-shelf hardware and software components. Delta-4 proposed, and built on, the concept that the property of dependability could be conferred on commercial processor systems if these systems were linked through a dependable communication system. The project has developed and validated such a communication system, known as MCS (Multi-point Communication System). MCS implementations on token ring (IEEE 802.5) and token bus (IEEE 802.4) local area networks have been achieved. An application program support environment, DELTASE (a prototype of the emerging ECMA Standard Support Environment for Open Distributed Processing), and a system administration software suite have also been developed. DELTASE fulfils the same objectives as, and uses similar technology to, the OSF Distributed Computing Environment. The applicability of Delta-4 concepts to off-the-shelf software has been demonstrated through an implementation of a dependable ORACLE relational database management system. This dependable RDBMS, which provides service continuity during database cloning operations following a failure, is used in both of the pilot applications described below. Prototype components of the architecture have been integrated, and demonstrated, at the project Experimental Site at the LAAS Laboratories in Toulouse. Two pilot-site application systems are now in preparation prior to commissioning and demonstration during 1991: An on-line Authorization Centre to support electronic payment using magnetic cards for Credit Agricole, an automotive production management, and manufacturing control and monitoring system for Renault. Major advances are support for incremental, service-by-service, dependability using fail-silent and/or fail-uncontrolled processors as required. Redundant resources may be geographically separated for decreased risk of common-mode failures. Further the provision of mechanisms for on-line cloning of software components allowing systems to survive further faults during the repair process and the availability of a set of fault-tolerance techniques allowing optimization of performance, dependability and cost criteria were explored.
Model: loosely-coupled, client/server
Properties: UNIX-compatible, fault-tolerant, real-time support
Transparency: access, location, replication, failure
Running on: UNIX Workstations
Date: 1986 - 1991
Literature:
D. Powell (Ed.): "Delta-4: a Generic Architecture for Dependable Distributed Computing", Research Reports ESPRIT, ISBN No3-540-54985-4, Springer-Verlag, Berlin, Germany, 1991.
D. Powell, G. Bonn, D. Seaton, P. Verissimo and F. Waeselynck: "The Delta-4 Approach to Dependability in Open Distributed Computing Systems", in Proc. 18th. Int. Symp. on Fault-Tolerant Computing Systems (FTCS-18), (IEEE), pp.246-251, Tokyo, Japan, June 1988.
P. G. Ranea, J. M. Fray, Y. Deswarte and D. Powell: "The Security Approach in Delta-4": In Proc. European Teleinformatics Conf. (EUTECO 88), (North-Holland), pp.455-466, Vienna, Austria, April 1988.
G. Bonn, U. Bugel, F. Kaiser and T. Uslander: "Management of the Delta-4 Open, Distributed and Dependable Computing System", in Proc. IFIP TC6/WG6.6 Symp. on Integrated Network Management, (B. Meandzija and J. Wescott, Ed.), (Elsevier Science Publishers BV (North Holland)), pp. 573-584, Boston, MA, USA, May 1989.
Forest Baskett, Michael L. Powell and Barton P. Miller
DEMOS/MP is a message-based distributed operating system kernel. The major function provided by the DEMOS/MP kernel was location-transparent interprocess message passing; higher level operating system functions were provided by system level tasks running on top of the kernel. In DEMOS/MP, the kernel was responsible for providing the mechanism of process migration, while the process manager system task was responsible for making decisions about when to migrate processes.
Model: tightly coupled
Properties: process migration, message passing
Transparency: location
Running on: Cray, a number of Z8000 Computers
Date: 1977-1987
Literature:
M. L. Powell and B.P. Miller: "Process Migration in DEMOS/MP". ACM Operating Systems Review, Vol. 17, No. 5, Oct. 1983
Miller, B. P; Presotfoj D. L. and Powell, M. L: "DEMOS/MP: the development of a distributed operating system". Software Practice and Experience i7 43, 277-290
F. Baskett, J.H. Hoeard and J.T. Montaque: "Task communication in DEMOS". Proceedings of the 6th Symposium on Operating System Principles, November 1977, pp. 23-31
G.W. Luderer, H. Che, J.P. Haggerty, P.A. Kirlis and W.T. Marshall
DISTRIBUTED UNIX consists of two components: The S-UNIX sub-system provides a complete UNIX process environment enhanced by access to remote files. The F-UNIX sub-system is specialised to offer remote file services. A system can be configuered out of many computers which operate either under S-UNIX or the F-UNIX operating subsystem. The file servers together present the view of a single global file system. A single service view is presented to any user terminal communicating to one of the S-UNIX sub-system. Computers communicate with each other through a high-bandwidth virtual circuit switching.
Model: workstation, modular, integrated
Properties: point-to-point, UNIX-compatible, global file system
Transparency: access, naming
Running on: DEC PDP-11
Date: 1979 - 1981
Literature
G. W. R. Luderer, H. Che, J. P. Haggerty, P. A. Kirslis, and W. T. Marshall: "A Distributed UNIX System Based on a Virtual Circuit Switch". ACM Proceedings of the 8th Symposium on Operating Systems Principles, Operating Systems Review, Vol. 15, No.5, December 1981, pp.160-168.
Amnon B. Barak and Amos Shapir: "UNIX with Sattelite Processors", Software Practice and Experience, Vol. 10, pp. 383-392, May 1980 .
G. von Bochmann: "Architecture of Distributed Computer Systems," Lecture Notes in Computer Science No. 77, Springer Verlag, New York, 1979 .
G.L. Chesson: "Datakit Software Architecture", Proc. ICC 79, June 1979, Boston Ma, pp. 20.2.1-20.2.5 .
Shang Rong Tsai and Ru Jing Chen
DMINIX is a distributed version of MINIX operating system. The goal of DMINIX is to provide a powerful distributed processing environment on a network of personal computers. As the MINIX, DIMINIX is message-driven system. In the design of DMINIX, it is important to supply a highly reliable and network transparent IPC for the system and user processes because every service in DMINIX system is completed in message passing by way of IPC. The basic functions in the DMINIX include network transparent interprocess communication, distributed file system with file replication support and remote tasking support. The DMINIX kernel is responsible for interprocess communication multitasking support and low level interrupt handling.
Model: homogeneous, loosely-coupled
Properties: UNIX-compatible, message passing, process migration, micro kernel
Transparency: location, access, replication
Running on: IBM PC
Date: 1990 - 1991
Literature:
Shang Rong Tsai and Ru Jing Chen: "Interprocess Communication with Multicast Support in DMINIX Operating System". Microprocessing and Microprogramming 32 (1991), pp. 145-152.
Shang Rong Tsai and W.J. Ueng: "Remote Tasking in the DMINIX System". Proc. of the International Computer Symposium, Dec. 1990, Hsinchu, Taiwan, ROC, pp. 103-108.
P.J. Leach and Paul H. Levine
The Apollo Domain distributed operating system runs in workstations that are connected by a network and provides a transparent data access model. Local files and remote files stored in other workstations or servers are referenced and accesses by clients programs in exactly the same way. Any client program with the appropriate access rights can access any of the files and other data objects in the system, because UFIDs are used for naming and accessing both local and remote objects. Apollo Domain also implements a single-level storage model, mapping open files into a virtual address space of client processes, but all access to the single-level store is through the kernel.
Model: homogeneous, integrated, workstation
Properties: message passing
Transparency: location, access, migration, concurrency
Running on: Apollo Workstations
Date: 1979
Literature:
P. H. Levine, Yakup Paker, Jean-Pierre Banatre and Muslim Bozyigit: "The Apollo DOMAIN Distributed File System". Berlin 1987 Springer-Verlag, Distributed Operating Systems Theory and Practice, Vol. 28, NATO ASI Series F: Computer and Systems Sciences, 1987, pp.241-260.
P.J. Leach, Paul H. Levine, B.P. Douros, J.A. Hamilton, D.L. Nelson and B.L. Stumpf: "The architecture of an integrated local network", IEEE Journal on selected Areas in Communications, Vol SAC-1, No. 5, 1983, pp. 842-856.
L. Casey and N. Shelness
The Domain Structure argues for the use of a multi computer physical architecture in preference to a multi-processor architecture, and for dynamic distribution of functions and control as apposed to static allocatons of functions and hierachial control. The Domain Structure restricts sharing of items. It makes the management of the non shared items easier since they can required only at one computer at a time - essential sharing is also handled without central control The components of this system environment are domains, segments and virtual processors.
Model: minicomputer, multi-processor
Properties: virtual memory, multicast, Multiple Communications Primitives,
virtual processors
Transparency:
Running on:
Date: 1977-?
Literature
L. Casey and N. Shelness: "A Domain Structure for Distributed Computer Systems", Proc. of the Sixth ACM Symposium on Operating Systems Principles, November 1977, pp. 101-108.
L.M. Casey: "Computer Structures for Distributed Systems", Ph.D. Thesis, CST-2-77, Computer Science Dept. Edingburgh University, Jan. 1977.
F.C. Colon: "Coupling Small Computers for Performance Enhancement", AFIPS NCC Vol . 45 1976, pp. 755-764.
C.C. Forster: " A View of Computer Architecture", CACM Vol. 15 No. 7 Jul. 1972, pp. 557- 565.
Marc Pucci and Jim Alberi
Dune is a distributed operating system, that provides uniform distribution of both the process space and the file system space across a collection of single board computers connected via backplanes, ethernet and tocken rings. The system supported process migration and automatic load balancing. DUNE is an enhanced RPC model of interprocess communication that is generally efficient for many types of network, even non traditional ones. It is based on optional hints supplied by client of an operation, which enable medium specific optimisations in an uniformly structured interface. DUNE supports dynamic rebindings of communication protocols, which is necessary for the efficient treatment of migratable system object.
Model: multi-processor, client/server, loosely-coupled, shared-
memory, kernelized/micro kernel
Properties: process migration, UNIX-compatible, RPC, point-to-point datagram,
replication, channels, load balancing
Transparency: location, access, migration
Running on: MC68000
Date: 1988-1990
Literature
Marc Pucci and Jim Alberi: "Using Hints in Dune Remote Procedure Calls". Computing Systems Journal, Vol. 3, No. 1, Winter 1990.
Marc Pucci and Jim Alberi; "Dune - A Distributed Operating System for the Evolving Telecommunications Network". Proc. Second National USING Conference, 1988.
Marc Pucci and Jim Alberi: "Experiences with Efficient Interprocess Comminication in Dune" Proceedings of Workshop on Distributed and Multiprocessor Systems, Ft. Lauderdale, FL, USA, October 1989.
J.L. Alberi and M.F. Pucci: "The DUNE distributed operating system", Proceedings of the First Using National Conference, Denver, CO, September 1988.
Ami Litman
DUNIX is a distributed operating system, that integrates several computers, connected by a packet switching network, into a single UNIX machine. The system appears to its users as a single large computer running UNIX. This illusion is created by cooperation of the computer's kernels. DUNIX provides a global, location-transparent name space for files, processes devices, etc., using a bare-machine kernel. Has a superroot under which all the subdirectories are mounted. The system is nicely structured into user code (which isn't aware of location, and just sees the standard UNIX interface), the upper kernel, which isn't aware of location, and the lower kernel, which is, and is accessed by the going through the "Switch". Unlike LOCUS, DUNIX provides a single, location independent name space for the system's devices. LOCUS, for example, has a separate /tmp for each system since it wants to make sure that temp file names can be kept unique, with the non-unique process ids it has (since the mktemp call uses the process id to cons up a file name). Performance is good - compiling a big program on a machine remote from the source files is faster than completely local 4.2BSD; completely local DUNIX is, of course, even better. This system was derived in part from MOS. (See A. Barak and A. Litman) This is a nice system design, and they have good performance numbers. The system, is also in use at Bellcore. DUNIX is an operating system that integrates several computers, connected by a packet switching network, into a single UNIX machine. As far as the users and their software can tell, the system is a single large computer running UNIX. This illusion is created by the cooperation of the computers' kernels. The illusion is so complete, that the kernels are able to migrate any process from one computer to another without disturbing the behavior of the process. The DUNIX kernel is procedure call oriented and follows the principle of information hiding. The code that implements a specific system call (e.g., open) does not know whether the object in question (the file) is local or remote. This uniformity makes the kernel small and easy to maintain. The system behaves gracefully under subcomponents' failures. Users who do not have objects (tty, files, processes) in a given computer are not disturbed when that computer crashes. The system administrator may switch a disk from a sick computer to a healthy one, and remount the disk under the original path-name. After the switch, users may access files in that disk via the same old names. DUNIX exhibits surprisingly, high performance. For a compilation benchmark, DUNIX is faster than 4.2 BSD, even if in the DUNIX case all the files in question are remote. A DUNIX installation consisting of five VAXes connected by an Ethernet has been running in Bell Communications Research since September 1986. This system is on the Internet network and speaks the TCP/IP protocols. Researchers in Bellcore and other institutes are porting DUNIX to Suns and Micro-VAXes.
Model: integrated
Properties: UNIX-compatible, process migration, WAN support
Transparency: access, location, migration
Running on: Suns and Micro-VAX
Date: 1986
Literature:
A. Litman: "The DUNIX Distributed Operating System". Bell Communications Research, Operating Systems Review, Vol. 22, No.1, pp. 42-51, January 1988.
Guy. T Almes, Andrew. P Black, Eduard. D. Lazowska, and Jerre. D. Noe
Eden is an experiment in designing, building, and using an integrated distributed operating system. The Eden system consists of a kernel, a programming language (EPL) and user-level code (library). The Eden kernel is implemented as a Unix process which communicates via IPC. A program in Eden consists of a number of distributed objects, called Ejects. These objects are referenced by a capability. This does not contain any location information, so objects are mobile. A checkpointing mechanism is supported for recovery.
Model: partially integrated
Properties: object-oriented, UNIX-compatible, process migration, capabilities,
atomic transactions
Transparency: location, access, replication, failure
Running on: Intel iAPX 432, iMAX, VAX/VMS
Date: 1980 - 1985
Literature:
Almes, G. T; Black, A. P; Lazowska, E. D. and Noe, J. D.: "The Eden system: A Technical Review". IEEE Transactions on Software Engineering, SE-11(1), pp. 43-59, January 1985.
Eduard. D. Lazowska, H.M. Levy, Guy. T Almes, M.J. Fischer, R.J. Fowler and S.C. Vestal: "The Architecture of the Eden System". In Proc. of the Eighth ACM Symposium on Operating System Principles, ACM Operating Systems Review, Vol. 15, No. 5, Dec. 1981, pp. 148-159.
W.H. Jessop, D.M. Jakobson, J.D. Noe, J.L. Baer and C. Pu: "The Eden transaction based file system", In Proc. of the 2nd Symposium on Reliability in Distributed Software and Databases, July 1982, pp. 163-169.
C. Pu: "Replication and Nested Transactions in the Eden Distributed System", University of Washington, Phd Dissertation, 1986.
Pradeep K. Sinha, Mamoru Maekawa, Kentaro Shimizu, Xiaohua Jia, Hyo Ashihara, Naoki Utsunomiya, Kyu S. Park and Hirohiko Nakano
GALAXY is a distributed operating system, designed from scratch for use in local and widearea networks. Therefore broadcast protocols were eliminated and global-locking and time-stamp-ordering mechanisms were avoided for maintaining the global state of the system. Multiple-level interprocess communication mechanisms were used to meet the various communication needs of different applications. The concept of variable weight processes gives flexibility and efficiency in data sharing and process scheduling.
Model: loosely coupled
Properties: WAN support, UNIX-compatible, object-oriented, message passing,
lightweight processes
Transparency: access, replication, location
Running on: IBM RT/PC
Date: 1990
Literature:
Pradeep K. Sinha, Mamoru Maekawa, Kentaro Shimizu, Xiaohua Jia, Hyo Ashihara, Naoki Utsunomiya, Kyu S. Park and Hirohiko Nakano: "The Galaxy Distributed Operating System". IEEE Computers ?
Kentaro Shimizu and Mamoru Maekawa: "Hierarchical Object Groups in Distributed Operating Systems". The 8th International Conference on Distributed Computing Systems
Jean-Pierre Banâtre, Michel Banâtre and Florimond Ployette
Gothic is a language and system for reliable distributed programs, is based on the theory of Fragmented Objects invoked via "multi-functions", supported by the language. Gothic is based on the architecture of a fault-tolerant multi-processor based on stable storage and provides virtual memory management. The integrated environment seen by Gothic users is a collection of software sub-systems operating on the set of node machines. Each machine supports the Gothic kernel which provides the set of primitives to implement objects and multi-procedures management.
Model: multiprocessor
Properties: object-oriented, fault-tolerant
Transparency: replication, location, access
Running on: SPS-7
Date: 1986
Literature:
Jean-Pierre Banâtre, Michel Banâtre and Florimond Ployette: "An overview of the Gothic distributed operating system". Rapport de recherche 504, Cedex, France 1986 INRIA, March 1986
Jean-Pierre Banâtre, Michel Banâtre and G. Muller: "Main Aspects of the Gothic Distributed System.", Research into Network and Distributed Applications, Elsevier Science Publishers B.V. (North-Holland), 1988, pp. 747-760
A. Kermarrec
The GOTHIX system, built on UNIX, provides facilities to implement object fragmentation and replication. It is integrated and distributed. From the user point of view, it looks like traditional centralized system mainframe based system and only the application program developers will take advantage of the properties offered by the distribution.
Objects provided in GOTHIX are of three types:
1. directories
2. files or segments
3. and fragmented files
All other object are to be built from these kind of objects.
Model: multi-processor, kernelized/micro kernel, integrated
Properties: UNIX-compatible, crash recovery, stable storage
Transparency: concurrency, replication
Running on:
Date: 1988 - ?
Literature
A. Kermarec: "An overview of the Gothix distributed system". Proceedings of the EUUG Spring 1988 Conference; April 1988, pp. 69-78.
R. Balter, J. Bernadat, D. Decouchant, A. Duda and A. Freyssinet
Guide is an object-oriented distributed operating system for local area network. It embodies the object-oriented architecture defined in the COMANDOS Esprit Project. Guide is a joint project of Bull and the IMAG Research Institute, which have created the Bull-IMAG joint Research Laboratory. Guide is designed as a set of distributed services, which may be viewed as the upper layers of a distributed operating system. It provides location transparency of network resources to the application layer. When an object needs access to an object located on a remote machine, it extends itself to that machine, and maps the object in. Guide is a convenient tool for developing transparently distributed applications that use persistent data. The intended application domain is cooperative processing. Guide is still a research prototype, with the deficiencies that may be expected at this stage.
Model: loosely coupled
Properties: object-oriented, micro kernel
Transparency: access, concurrency, location
Running on: Sun-3/60, Sun-3/80, Sun-4, Sun-i386, Bull DPX 1000 and
DPX-2, DEC Decstation3100
Date: 1986
Literature:
R. Balter, S. Krakowiak, M. Meysembourg, C. Roisin, X. Rousset de Pina, R. Scioville and G. Vandôme: "Principes de Conception du Systéme Réparti GUIDE". Bigre+Globule, No. 52, pp. 3-23, December 1986.
D. Decouchant, A. Duda, A. Freyssinet, H. Nguyen Van, M. Riveill and X. Rousset de Pina: "Guide: Un Systéme Réparti à Objet". Actes Convention Unix 89 Paris AFUU, pp. 297-316, March 1989.
D. Decouchant, et al.: "GUIDE: The implementation of the COMANDOS object-oriented distributed system architecture". Proceedings of the EUUG autumn Conference CASCais/Portugal 1988.
FTP: imag.fr
Marvin Gentleman, Marceli Wein and Richard Stroobosscher
Harmony is an object-oriented multitasking multiprocessor operating system for real-time control. Harmony is portable across different target computers and development hosts. As most embedded systems, Harmony is not designed to support program development. Instead, program development can be done on any host computer with a cross compiler. Harmony is open in that it does not distinguish system supplied servers from user supplied servers and it is easy to use the system on many different configurations of hardware and to add support for new peripherals. Also there is a uniform connection mechanism to servers.
Model: multiprocessor
Properties: real-time support, object-oriented, message passing, lightweight processes
Transparency: location, access
Running on: 68000, VAX 750, ATARI ST 520/1040
Date: 1983-1989
Literature:
S.A. MacKay, W.M. Gentleman, D.A. Steward and M. Wein: "Harmony as an Object-Oriented Operating System". Proceedings of the ACM-SIGPLAN Workshop on Object-Based Concurrent Programming, in SIGPLAN Notices, Vol.24, No. 4, pp. 209-211, April 1989.
J. James, K. Rowe, L. Gray, B. Vishnubhatla, C.F. Wan and M. Wilson: "Experience porting the Harmony Operating System". IEEE RTSS, pp. 88-99, 1985.
Garnett N.H., King Tim and King Jessica
Helios is a distributed UNIX-like operating system for transputers. The user and programmer interfaces are similar to the ones of a real UNIX. The well-known C development language is supplied. Helios manages all the resources within the network and the communications through the network. Helios is composed of a kernel located on each node. The kernel implements a message-passing communication scheme in datagram mode. Messages are transmitted and received in mail-boxes named ports. The kernel deals with the message routing and provides the processes with semaphores as synchronization tools. The other system functions are implemented as servers.
Model: tightly-coupled
Properties: message passing, UNIX-compatible, micro kernel
Transparency: location, access
Running on: Transputers, T800
Date: 1987
Literature:
Perihelion Software, Ltd.: "Helios Developer's Manual", 1987, Perihelion Software, Ltd.
Perihelion Software, Ltd.: "Helios Operating System", 1989, Prentice-Hall.
D. S. Miller, R. W. Fisher, B. R. Millard, and V. G. Murthy
Herbert-II is a distributed operating system which runs on a local area network of three 6809 based Codex Intelligent Terminal System computers fully connected by MC6821 PIA parallel interfaces. The Codex ISOS operating system at each node has been extended to include physical, link, network, transport and session communication layers normally added on as an afterthought in access methods or utilities in conventional distributed system architectures. Herbert-II is an object-oriented UNIX-like operating system which supports multiprogramming on multiple processors.
Model: multi-processor, object-oriented, loosely-coupled
Properties: UNIX-compatible, atomic transactions, channels, multi-programming
Transparency: location
Running on: 6809 based Codex Intelligent Terminal System Computer
Date: 1983 - ?
Literature
D. S. Miller, R. W. Fisher, B. R. Millard, and V. G. Murthy: "A distributed operating system for a local area network". Phoenix, AZ, USA 1983 IEEE, New York, USA, p: ix +598, Second Annual Phoenix Conference on Computers and Communications 1983 Conference Proceedings, pp. 14-16, March 1983.
D.S. Miller: "Resource Allocation in Multi-processor Distributed Operating Systems", Proceedings of ACM Computer Science Conference, Feb. 1988.
B. R. Millard: "Resource Allocation in a Multiple Processor Operating System", MS Project, Washington State University Computer Science Department, 1981.
V.G. Murthy: "Process Creation and Communication in Distributed Operating Systems", MS Project, Wachington State University Computer Science Department, 1981.
Yolande Berbers and Pierre Verbaeten
Hermix is a distributed operating system being designed for a heterogeneous environment of computer systems: workstations and/or mini-computers, dedicated machines, and a pool of various processors which are available either for running certain jobs to offload the other processors or when a special processor is needed. The potential advantages of distributed systems which where found the most interesting for Hermix were in the first place flexibility, extensibility, the reconfiguration possibilities, and resource sharing.
Model: hybrid, heterogeneous, client/server
Properties: UNIX-compatible, message passing, lightweight processes
Transparency: location, access, concurrency, migration
Running on: Motorola Exormacs 68000
Date: 1987
Literature:
Yolande Berbers and Pierre Verbaeten: "Design of the HERMIX distributed operating system: structural aspects". Microprocessing and Microprogramming 24, pp. 187-194, 1988
Yolande Berbers and Pierre Verbaeten: "Design of the HERMIX distributed operating system.", Proceedings of the 34th ISMM International Symposium Mini and Microcomputers, Lugano, Switzerland (June 1987)
M.-Y. Lai, K. Wilkinson, V. Lanin, H. Lee and U. Premkumar
JASMIN is a functionally distributed database system running on multiple microcomputers that communicate with each other via message passing. The software modules in JASMIN can be cloned and distributed across computer boundaries. They communicate with each other via message passing kernels. The kernel also supports multithread control and non preemptive scheduling. Besides the kernel, there are four major types of software modules in JASMIN, the file manager (FM), intelligent store (IS), record manager (RM) and data manager (DM). The FM supports the UNIX file system interface for program development and storing temporary data. The IS provides a page level interface and performs transaction management. The RM is an IS's client, which supports a record level interface and facilitates various access methods. The DM is an RM's client, which provides a relational level interface and does query optimization and execution.
Model: loosely-coupled
Properties: UNIX-compatible, message passing, atomic transactions
Transparency: location, concurrency, access
Running on: MC68000
Date: 1987 - 1989
Literature:
Lai, M.-Y; Wilkinson, K. and Lanin, V.: "On distributing JASMIN'S optimistic multiversioning page manager". IEEE Transactions on Software Engineering, 15(6), pp. 69-74.
J. E. Donnelly
The idea behind LINCS is, that the needs for economy, reliability, security, and privacy in distributed information system have suggested that such systems be constructed from modules operating in separate domains. Ideally the domain of each module would permit access to only those reources needed to accomplish its task. In practice it has proved difficult to provide such precise access control.
At the level of process-to-process communication there is the thorny problem of defining a resource independent protocol for communicating resource access. Several approaches to this problem are discussed, including a solution based on public key encryption.
At the level of human-to-process communication there is a similar problem of communicating access to resources. Here a person at a terminal needs to be able to indicate which resources should be made available to the process performing a request task. The advantages of a discriminating domain control at the process level are largely wasted if the human-to-process protocols fail to address this important issue.
Model: multi-processor, tightly-coupled
Properties: point-to-point, encryption, capability based, identity based,
Transparency:
Running on:
Date: 1979-1981
Literature
J. E. Donnelly: "Managing Domains in a Network Operating System", Proc. Conf. on Local Network and Distributed Office Systems, Online, pp. 345-361, 1981.
J.E. Donnelley: "A Distributed Capability System", Proc.of the Third International Conference on Computer Communication, Toronto, Ontario, August 3-6 , 1976.
J.E. Donnelly: "Components of a Network Operating System", Computer Networks 3,389 (1979). Also in Proc. Fourth Conference on Local Computer Networks, Minneapolis, Minnesota, October 22-23, 1979 IEEE, pp. 1-12.
J.E. Donnelly and J.Yeh: "Interaction Between Protocol Levels a CSMA Broadcast Network", Computer Networks 3,9 (1979).
Bruce J. Walker, Gerald J. Popek, Charles Kline, Greg Thiel and Alan R. Downing
LOCUS is a commercial, UNIX-compatible, distributed operating system that provides a very high degree of network transparency while at the same time supporting high performance and automatic replication of storage. By network transparency the authors mean that at the system call interface there is no need to mention anything network related. Knowledge of the network and code to interact with foreign sites is below this interface and is thus hidden from both users and programs under normal conditions. LOCUS is application code compatible with UNIX and performance compares favorably with standard, single system UNIX. LOCUS runs on a high bandwidth, low delay local network. It is designed to permit both a significant degree of local autonomy for each site in the network while still providing a network-wide location independent name structure. Atomic file operations and extensive synchronization are supported. Small, slow sites without local mass store can coexist in the same network with much larger and more powerful machines without larger machines being slowed down through forced interaction with slower ones. Graceful operation during network topology changes is supported. IPLocus is a Version of Locus for the Internet.
Model: loosely coupled, fully integrated, multiple-instance
Properties: process migration, UNIX-compatible, atomic transactions,
fault-tolerant, WAN support
Transparency: access, concurrency, location, migration, failure, replication
Running on: DEC PDP-11/45, VAX 750
Date: 1983-1986
Literature:
G. Popek, B. Walker, J. Chow, D. Edwards, C. Kline, G. Rudisin and G. Thiel: "Locus: A Network Transparent, High Reliability Distributed System". Communications of the ACM, pp. 169-177, 1981.
B. Walker, et al.: "The LOCUS distributed operating system". Proceedings of the 9th ACM Symposium Operating Systems on Principles, Vol. 17 No. 5, pp. 49-70, October 1983
G. Popek, B. Walker, J. Chow; D. Edwards, C. Kline, G. Rudisin and G. Thiel: "LOCUS: A Network Transparent, High Reliability Distributed System". Pacific Grove, CA, USA 1981, Proceedings of the 8th Symposium on Operating Systems Principles Operating Systems Review, Vol. 15, No.5, December 1981, pp. 169-177, 19 Refs Treatment PRACTICAL.
Bruce J. Walker: "Issues of Network Transparency and File Replication in the Distributed File System Component of LOCUS". UCLA CSD-830905, Sept. 1983.
Alan R. Downing and Gerald J. Popek: "Protocols for a Transparent, Internet, Distributed Operating System." IEEE Conference on CH, 1988, pp. 313-321.
Allison J. Mull and P. Tubin Maginnis
MINIX DOS is another distributed version of MINIX operating system. The goal of MINIX DOS is to provide network transparency and to show that the normal MINIX system can be distributed by adding a few extentions. In order to transform MINIX to a DOS , a number of componentes have been added and integrated into the existing structure of MINIX. These are the communikation manager, the resource manager, the network manager and an Ethernet-driver. Distributed processing has been acheived without additional system calls.
Model: workstation, datagram, synchronization, encryption, heavyweight, homogeneous, loosely-coupled, fully integrated, multiple-instance,
kernelized/micro kernel
Properties: UNIX-compatible, preemptive multitasking, traditional hierarchical naming, synchronous message passing, direct, rendezvous
Transparency: location, access
Running on: IBM PC
Date: 01.01.91 - 24.2.1992
Literature:
Allison J. Mull and P. Tubin Maginnis: "Evolutionary Steps Toward a Distributed Operating System: Theory and Implementation", Department of Computer Science, University of Mississippi.
Brett D. Fleisch, Gerald J. Popek
Mirage is a distribued shared memory system based on UNIX System V and LOCUS. A Distributed Shared Memory system which uses time counts to reduce thrashing in coherence strategies. After a process gains the rights to a page, it is guaranteed uninterrupted access to that page. Mirage is a DSM system implemented in the kernel of an existing operating system. The protocol used in Mirage is different from previous work in the following ways:
1. The model is based on page segmentation (DALE 68, DENN 70).
2. The writer of a page retains acess to that page for a fixed period of time independent of sub-
sequent read and write requests.
3. There may be upgrades or downgrades in the modes of pages that are distributed throughout
the network.
Model: loosely-coupled, shared-memory, kernelized/micro kernel
Properties: migration, UNIX-compatible
Transparency: location access, replication, concurrency
Running on: VAX 11/750
Date: 1988-1989
Literature
Brett D. Fleisch and Gerald J. Popek: "Mirage: A Coherent Distributed Shared Memory Design". 1989 UCLA, Proc. Twelfth ACM Symposium on Operating Systems, Operating Systems Review, Vol. 23, No.5, December 1989, pp.211-223.
Brett D. Fleisch: "Distributed Shared Memory in a Loosely Coupled Distributed System", San- Francisco CA, 1988, IEEE Compcon '88 February-March 1988, pp. 182-184 .
B.D. Fleisch: "Distributed Shared Memory in a Loosely Coupled Environment", Ph.D. Dissertation, University of California, Los Angeles, July 1989.
Amnon B. Barak, A. Litman and Richard Wheeler
MOSIX is an integrated, general-purpose, homogeneous, Unix-compatible distributed operating system, that integrates a cluster of loosely connected, independent computers into a single-machine UNIX environment and provides dynamic load balancing through process migration. The main properties of MOSIX are its high degree of integration, dynamic process migration, and the possibility to scale dynamically to a large number of nodes. Developed originally for a network of uniprocessor nodes, the current version of the system also supports nodes with multiple processors. MOSIX is network transparent and all nodes have a complete copy of the kernel so they can run autonomously. To provide for network transparency and process migration, the kernel is made up of two levels. The lower part is site-sensitive and tightly coupled with the hardware, while the upper part has no notion of the particular processor it is running on. User processes interface only with the upper part of the kernel, which provides a classic UNIX interface.
Model: integrated, multiple-instance, multiprocessor DOS
Properties: process migration, UNIX-compatible, fault-tolerant
Transparency: location, access, migration
Running on: PDP-11/23, MC68010, VAX, CADMUS/PCS, National 32000
Date: 1982
Literature:
Amnon Barak and Richard Wheeler: "MOSIX: An Integrated Multiprocessor UNIX". The Hebrew University of Jerusalem (Israel), Department of Computer Science
Amnon Barak: "The Evolution of the MOSIX MULTI-Computer UNIX System". The Hebrew University of Jerusalem (Israel), Department of Computer Science
Amnon Barak and A. Litman: "MOS: a multicomputer distributed operating system". Software Practice and Experience, 15(8), pp. 725-738
ykt@csl.sony.co.jp
Yasuhiko Yokote, Fumio Teraoka, Atsushi Mitsuzawa, Nobuhisa Fujinami, and Mario Tokoro
Muse is an object-oriented distributed operating system, which provides a new approach of an object architecture. In this architecture an object is a single abstraction of a computing resource in the system. Each object has a group of meta objects which provide an excecution environment. These meta objects constitute a meta space which is represented within the meta hierachie.
The novel features of this architecture include:
- the notion of an object and its meta objects gives programmers a clear abstraction of the
system
- reflective computing provides a basic mechanism to realize a self-advancing system
- the system is flexible and adaptable
Model: workstation, object-oriented
Properties: UNIX-compatible, fault-tolerant, real-time support
Transparency: replication, concurrency
Running on: Sony NEWS
Date: 1992-?
Literature
Y. Yokote, F. Teraoka, and M. Tokoro: "The Muse Object-oriented Distributed Operating System: An Overview". Technical.
M.Shapiro: "Structure and Encapsulation in Distributed Systems: The Proxy Principle", In Proc. of the 6th International Conference on Distributed Computing Systems, May 1986.
Anand R. Tripathi
Nexus is a distributed operating system designed to support experimental research in fault-tolerance techniques and object-oriented programming in distributed systems. The Nexus programming environment consists of objects, which are instances of abstract data types. Inheritance of types and multiple implementations for a type are supported by the system. Operations on objects are invoked based on the remote procedure call paradigm and executed as atomic actions with provisions for application-controlled checkpointing and restart within actions. The Nexus kernel also supports parallel remote procedure calls, interobject communication and location transparency in accessing objects.
Model: loosely coupled
Properties: atomic transactions, object-oriented, message passing,
UNIX-compatible, fault-tolerant
Transparency: access, location, failure
Running on: Sun-3
Date: 1987
Literature:
Anand R. Tripathi: "An overview of the Nexus Distributed Operating System Design". IEEE Transactions on Software Engineering Vol. 15 No. 6, June 1989
Anand Tripathi, Adel Ghonami and Thomas Schmitz: "Object Management in the NEXUS Distributed Operating System". 1987 IEEE, Spring COMPCON '87, February 1987, pp.50-53.,
Willy Zwaenepoel and Keith A. Lantz
Perseus was designed to be portable by virtue of its kernel-based structure and its implementation in Pascal. In particular, machine-depentent code is limited to the kernel and most operating systems functions are provided by server processes, running in user mode. Perseus was designed to evolve into a distributed operating system by virtue of its interprocess communication facilities, based on message passing.
Model: workstation, client/server, micro kernel
Properties: message passing, UNIX-compatible, asymetric addressing
Transparency:
Running on: VAX-11/780, SUN MC68000
Date: 1979 - 1981
Literature
Willy Zwaenepoel and Keith A. Lantz: "Perseus: Retrospective on a Portable Operating System", Software-Practice and Experience, Vol. 14, pp. 31-48, 1984.
W. Zwaenpoel and K. A. Lantz: "Perseus: Retrospective on a Portable Operating System", Computer Systems Laboratory, Departments of Computer Science and Electrical Engineering, Stanfort Univerity, Stanfort, CA 94305, USA.
L. Gerlach, K. Malowaniec, H. Scheidig, R. Spurk
In POOL a system is described as a collection of objects. An object can be thought of as a kind of box, containing some data and having the ability to perform some actions on these data. This lies in two mechanism:
1. An object can have a set of methods, a kind of procedures, which can access and change the
values of the variables
2. An object has a so-called body, a local process that can excecute in parallel with the bodies of
all other objects in the system
Model: multiprocessor, object-oriented
Properties: point-to-point, asynchronous message passing, modular
Transparency:
Running on:
Date: 01.01.84 - ?
Literature
L. Gerlach, K. Malowaniec, H. Scheidig, R. Spurk: "The Distributed System POOL", Experiences with Distributed Systems, Proc. International Workshop, Kaiserslautern, FRG, Springer Verlag, Sept. 1987, pp. 124-161.
Pierre America: "POOL: Design and Experience", ESPRIT projects 415, 2427, and 3020, and in the Dutch national PRISMA project, Philips Research Laboratories, JA Eindhoven, Netherlands.
Keeffe, D; Tomlinson, G. M; Wand, I. C., and Wellings, A. J.
PULSE is an Ada-based distributed operating system, which provides an interface similar to UNIX. The ADA-task is used as the process model. Pulse consists of two main parts, the kernel and the storage system.
Model: loosely-coupled
Properties: UNIX-compatible, point-to-point, synchronization, replication, RPC,
ADA-based
Transparency: access, replication, location
Running on: LSI-11/23
Date: 1985 -
Literature
Keeffe, D; Tomlinson, G. M; Wand, I. C., and Wellings, A. J: "PULSE: An Ada-based Distributed Operating System".,APIC Studies in Data Processing Series, London, Academic Press, APIC Studies in Data Processing, 6, 1985.
Tomlinson, G. M; Keeffe, D; Wand, I. C., and Wellings, A. J: "The PULSE distributed file system". Software Practice and Experience, 15(11), pp. 1087-1101, November 1985.
G. Gerrity, A. Goscinski, J. Indulska, W. Toomey and W.-P. Zuh
The Research Oriented Distributed Operating System (RHODOS) is designed for high-performance. It consists of a fast and small nucleus, responsible for interrupt handling, primitive interprocess communication, and context switching, a kernel which is a set of servers (managers) for process, IPC, migration, data collection, network, and device drivers and system servers, such as a name server, load balancing server, file server authentication server. All RHODOS processes communicate via messages through ports.
Model: integrated
Properties: micro kernel, message passing, process migration
Transparency: location, access
Running on: Sun
Date: 1988
Literature:
G. Gerrity, A. Goscinski, J. Indulska, W. Toomey and W.-P. Zuh: "The RHODOS Distributed Operating System". Technical Report CS 90/4, University College, The University of New South Wales, Australia
J. E. Ball, J. Feldman, J. Low, R. Rashid, and P. Rovner
RIG-system provides convenient access to a wide range of computing facilities. The system includes 5 large minicomputers in a very fast internal network, disk and tape storage, a printer, plotter and a number of display terminals. These are connected to larger campus machines and to the Arpanet. In a world where networks of diverse computing resources are growing and interwining, there is a pressing need for systems which provide access to a variety of computers and serve as intelligent gateways for their use.
Model: mini-computer, kernelized/micro kernel, loosely-coupled
Properties: UNIX-compatible, WAN support, asynchronous message passing
Transparency:
Running on:
Date: 1976-1980
Literature
J. E. Ball, J. Feldman, J. Low, R. Rashid, and P. Rovner: "RIG: Rochesters Intelligent Gateway: Systems Overview", IEEE Transactions on Software Engineering, Vol. SE-2, No. 4, Dec. 1980.
E. Ball; J. Feldman, J. Low; R. Rashid, and P. Rovner: "RIG, Rochester's Intelligent Gateway: System Overview", IEEE Transactions on Software Engineering, Vol. SE-2, No.4, December 1976, pp. 321-328.
M.H. Solomon, R.A. Finkel and R. Tischler
ROSCOE is an operating system that allows a network of microcomputers to cooperate to provide a general-purpose computing facility. All the processors are identical, there is no shared memory and no assumptions are made about the connection topology. The network appears to the user to be a single powerful machine. A process runs on one machine, but communicating processes have no need to know if they are on the same processor and no way of finding out. Communication is by message passing along links, there being no notion of a process address. The fundamental concepts of Roscoe are files, programs, core images, processes, links, and messages.
Model: integrated, loosely coupled
Properties: message passing, process migration
Transparency: location, access, migration
Running on: DEC LSI-11
Date: 1978
Literature:
M.H. Solomon and R.A. Finkel: "The ROSCOE distributed operating system". In Proceedings of the 7th Symposium on Operating Systems Principles (Pacific Grove, Calif., Dec. 10-12) Proc. 1979 Annual Conference ACM, New York, pp. 108-114, March 1979.
M.H. Solomon, R.A. Finkel and R. Tischler: "The Roscoe resource manager." COMPCON 79 Digsest of Papers (Feb. 1979), IEEE, New York, pp. 88-91.
J.H. Kepecs and M.H. Solomon
SODA is a small and simplified, but interesting operating system for distributed applications. It lies somewhere between a smart communications front end and a dump OS kernel. The "RISC of operating systems." An individual node in a SODA System consists of a pair of processors: The client processor and the kernel processor, which share access to common memory.
Model: multi-processor, client/server, kernelized/micro kernel, shared memory
Properties: asynchronous message passing, non-blocking
Transparency:
Running on:
Date: 1985-?
Literature
J.H. Kepecs and M. Solomon: "SODA: A Simplified Operating System for Distributed Applications". ACM, 3rd ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, August 1984.
Jonathan Kepecs and Marvin Solomon: "SODA: A Simplified Operating System for Distributed Applications", Operating Systems Review, Vol. 19, No.4, October 1985, pp.45-56.
W. D. Sincoskie and D. J. Farber
The Series/1 Distributed System (SODS) project at the University of Delaware was concerned with the design and construction of a distributed processing environment. The SODS project consists of three major parts: the operating system (SODS/OS), the file system (SODS/FS), and a local communications network. The authors describe SODS/OS, the distributed operating system for the IBM Series/1. SODS/OS is currently running on a two machine system. The machines are connected by a high speed point-to-point communication device.
Model: mini-computer, loosely-coupled
Properties: UNIX-compatible, point-to-point, datagram/messages, migration
Transparency: concurrency
Running on: IBM Series/1
Date: 1971-1980
Literature
W. D. Sincoskie; D. J. Farber: "SODS/OS: A Distributed Operating System for the IBM Series/1", Department of Electrical Engineering, University of Delaware Newark, DE, USA, ACM Operating Systems Review (USA), Vol. 14, No.3, pp.46-54, July 1980.
Marc Shapiro, Yvon Gourhant, Sabine Habert, Laurence Mosseri, Michel Ruffin and Céline Valot
SOS is an object-oriented distributed operating system, which provides support for arbitrary, user-defined, typed objects within a simple object-model. The system implements an generic mechanism for object migration, and supports Fragmented Objects, spread across multiple address spaces. The SOS system supports both fragmented and local elementary objects, object migration, persistent, dynamic linking and arbitrarily complex user-defined objects. Migration and storage preserve the data, the structure, and the type of the object. SOS maintains prerequisites, allowing the C++ run-time to implement dynamic type checking and linking. SOS system services are structured as FOs. They include a distributed object manager, a user-centered name service, a storage service, a communication service (supporting a library of protocol object types: datagrams, RPC, multicast, atomic multicast, etc.). Applications built using SOS include a multimedia document manager. SOS is a part of the SOR project at INRIA.
Model: server/client
Properties: micro kernel, message passing, process migration, object-oriented,
UNIX-compatible, atomic transactions, multicasting
Transparency: access, location, failure
Running on: Sun-3
Date: 1988
Literature:
Marc Shapiro, Yvon Gourhant, Sabine Habert, Laurence Mosseri, Michel Ruffin and Céline Valot: "SOS: An Object-Oriented Operating System - Assessment and Perspectives". Institut National de Recherche en Informatique et en Automatique, pp. 287-338, December 1989.
Boddyi. D. E: "SOS: A monitor-based operating system for instruction". ACM SIGPLAN Notices, 23(1), 115-124.
FTP: nuri.inria.fr /INRIA/publication/SOR
M. N. Nelson, B. B. Welsch and J.K. Ousterhout
Sprite is a distributed operating system, which provides transparent, efficient, and preemptable remote execution of processes. Sprite is optimized to support a particular RPC protocol with at most once semantics. It's remote execution facilities are automatically invoked by high-level application programs such as a parallel make utility. Sprite maintains the notion of a "home node" for all processes, where they originated. Pre-copying is not supported in Sprite for several reasons.
Model: client/server
Properties: process migration
Transparency: access, replication, concurrency, location
Running on: SUN-3
Date: 1988
Literature:
John K. Ousterhout, Andrew R. Cherenton, Frederick Douglis, Michael N. Nelson and Brent B. Welch: "The Sprite Network Operating System". IEEE Computer, Vol. 21 No. 2, February 1988, pp. 23-36.
FTP: sprite.berkeley.edu
yoyodyne.mit.edu
Andrew Birrell, P.R. McJones, G.F. Swart and C.P. Thacker
TAOS is the UNIX-compatible operating system for the Firefly multiprocessor workstations. The concept of multiple treads of control is supported. The formal specification language larch was used to specify the synchronization primitives. SCR have also developed an associated software environment TOPAZ, for research into multiprocessing and distributed personal computing.
Model: multiprocessor
Properties: micro kernel, UNIX-compatible, lightweight processes
Transparency: location, access
Running on: Firefly
Date: 1987
Literature:
A. D. Birrell and J. V. Guttag and J. J. Horning and R. Levin: "Synchronization Primitives for a Multiprocessor: A Formal Specification". Proceedings of the Eleventh ACM Symposium on Operating Systems Principles, pp. 94-102, November 1987.
Paul R. McJones and Garret F. Swart: "Evolving the Unix System Interface to Support Multithreaded Programs". SRC Report 21, DEC Systems Research Center, Palo Alto, California (USA), September 1987.
Charles P. Thacker, Lawrence C. Stewart and Edwin Satterthwaite, Jr., H.: "Firefly: A Multiprocessor Workstation". SRC Report 23, DEC Systems Research Center, Palo Alto, California (USA), December 1987.
D.R. Cheriton, T.P. Mann, P.J. Roy and K.A. Lantz
V is a distributed operating system of the process-message type. The system is structured as a relatively small kernel, a set of service modules various run-time libraries and a set of commands. Performance of the process migration mechanism is a key concern for the V system. The time a process is suspended during migration is minimized in the V-System through the use of a technique called pre-copying. The V-System uses very light-weight processes to construct programs. Several processes in a single address space may be combined to form an application. They communicate via synchronous message passing. There is no concept of capabilities in the V system. Communication processes are part of the kernel.
Model: loosely-coupled, fully integrated, single-instance DOS
Properties: process migration, lightweight processes, message passing, micro kernel
Transparency: access, location, concurrency
Running on: Sun Workstations connected via Ethernet
Date: 1984
Literature:
David R. Cheriton: "The V Distributed System". Computer Science Department, Stanford University, March 1987.
David R. Cheriton: "The V Kernel: a software base for distributed systems". IEEE Software, 1(2), pp.19-42.
David R. Cheriton and W. Zwaenepoel: "Distributed process groups in the V kernel". ACM Transactions on Computer Systems, 3(2), pp. 77-107.
David R. Cheriton and W. Zwaenepoel: " The Distributed group V-kernel and its performance for diskless workstations". ACM, In Proceedings of the 9th Symposium on Operating System Principles, New York, pp. 128-140.
Apple Computer's Advanced Technology Group (ATG), Cupertino, USA
Ross Finlayson, Mark D. Hennecke, and Steven L. Goldberg
Vanguard is an experimental object-oriented distributed system under development at Apple's Advanced Technology Group. Much of the Vanguard design is based upon that of Stanford's V-System. Like the V-System, Vanguard is defined by a programming language-independent message protocol suite, which in turn is built upon VMTP - a reliable request-response transport-level protocol. Concepts such as decentralized character-string naming, and process groups, originally developed for the V-System, have also been adopted by Vanguard. Because Vanguard's message protocols are object-oriented, it also has much in common with Cronus. However, unlike Cronus, which exists sloely as a system hosted on top of an existing operating system, Vanguard is intended to operate also as a complete operating system. The basis of Vanguard is a set of general communication protocols for invoking and managing distributed objects; these protocols are analoguus to the remote procedure call protocols used by many current distributed systems.
Model: workstation, homogeneous, loosely-coupled, kernelized/micro kernel,
object-oriented
Properties: virtual memory, datagrams, WAN-support, synchronization, preemptive
multitasking, migration, global naming, synchronous message passing,
at least once transactions
Transparency: location, access
Running on: Macintosh
Date: 1990 - ?
Literature:
Ross S. Finlayson, Mark D. Hennecke, Steven L. Goldberg, John L. Coolidge, Amit G. Parghi, and Edward W. Sznyter: "Object-Oriented Communication and Structuring in Vanguard". Proceedings of the International Workshop on Object-Orientation in Operating Systems, Huntsville, Palo Alto, Carlifornia, October 1991.
Ross S. Finlayson, Mark D. Hennecke, and Steven L. Goldberg: "Vanguard: A protocol suite and OS kernel for distributed object-oriented environments". Proceedings of the IEEE Workshop on Experimental Distributed Systems, Huntsville, Alabama, 1990
Nancy P. Kronenberg, Henry M. Levy and William D. Strecker
A VAX cluster has characteristics of both loosely- and tightly coupled systems. On one hand, a VAXcluster has separate processors and memories connected by a message-oriented interconnect, running several copies of a distributed VAX/VMS operating system. On the other hand, the cluster relies on close physical proximity, asingle security domain, shared physical access to disk staorage and high-speed memory-to-memory block transfer between nodes. The goals of the VAXcluster multicomputer system are high availability and easy extensibility to al large number of processors and device controllers. In contrast to other highly available systems, VAXcluster is built from general-purpose, off-the-shelf processors and a general-purpose operating system. A key concern in this approach is system performance. Two important factors in the perfomance of a multicomputer system are the software overhead of the communications architecture and the bandwidth of the computer interconnect.
Model: minicomputer, loosely-coupled, homogeneous, shared-memory,
multiple-instance
Properties: virtual memory, crash recovery, monolithic, datagram, point-to-point,
replication, synchronization, identity based, RPC, traditional hierarchical naming, shared memory, synchronous message passing,
Transparency: access, concurrency, failure, partially integrated
Running on: VAX 700-11, VAX/8600
Date: 01.01.85 - ?
Literature:
Nancy P. Kronenberg, Henry M. Levy and William D. Strecker: "VAXcluster: A Closely-Coupled Distributed System". ACM Transactions on Computer Systems, Vol. 4, No. 2, May 1986, Pages 130-146.
Francesco Tisato and Roberto Zicari
The Cnet project began in fall 1980, with the goal of designing and implementing a distributed system based on a local area network architecture and providing tools and methologies for programming distributed applications. The basic configuration of the system consists of a set of hosts connected by a local area network. The software architecture is bulit upon these hosts and consists of two layers: a user layer, composed by a set of abstract machines, called Virtual Nodes, and a lower layer which includes the run-time support for Virtual Nodes and the management of the host's resources.
Model: workstation, homogeneous, client/server, loosely-coupled,
partially integrated, kernelized/micro kernel
Properties: channels
Transparency: location, access, concurrency, migration
Running on: Olivetti M40 with Zilog Z8001
Date: 01.01.80 - 01.01.84
Literature:
F. Tisato and R. Zicari; "The Xcode Machine". Proc. of the Third Symposium on Microcomputer and Microprocessor Applications, Budapest, Hungary, October 1983, and ACM Sigsmall Newsletter, 10, 1, 1984.
F. Tisato and R. Zicari; "Mechanisms for Dynamic Configuration of a Locally Distributed System". IEEE 10th Conference on Local Computer Networks, October 1985, Minneapolis.
Douglas Comer, Fossum, Munson, and Stevens
XINU is an operating system with an elegant, hierarchical design which is easy to understand. Later it was extended by internetwork communication, remote interprocess communication, and a remote file system. XINU internetworking supports address determination at boot time, address resolution at run time, a syntactic name space and a protocol for name resolution. An interesting part of the XINU remote file system is the stateless fileserver.
Model: workstation, minicomputer, heterogeneous, client/server,
loosely-coupled, partially integrated, multiple-instance, monolithic
Properties: UNIX-compatible, virtual memory, WAN support, datagram,
standard protocols, synchronization, encryption, identity based,
preemptive multitasking, name servers, global traditional hierarchical
naming, synchronous message passing
Transparency: location, naming
Running on: Sun, IBM PC, DEC VAX 11/780, MicroVax
Date: 01.01.84 - ?
Literature:
Douglas Comer: "Operating System Design Vol. 1 The Xinu Approach", 1984, ISBN 0-13-637539-1, Prentice Hall, College Marketing Department, Englewood Cliffs
Douglas Comer: "Operating System Design Vol. II Internetworking with Xinu", 1987, ISBN 0-13-637414-X
S. J. Pratt
Alchemy is a three-dimensional distributed operating system model, which reflects both the interfaces between the distributed operating system kernel and the local standalone operating system, and the amount of indirect interfacing between individual nodes to effect global control. Segmenting and distributing the global control functions throughout the network will depend upon the individual processor's spare capacity for performing such additional tasks. Conversely application processes may be sent to the nodes where the demand placed upon it by effecting global control issues are least. As a consequence it is conceivable that one or more nodes would be supportive servers leaving the reminder nodes with the simple function of monitoring and reporting upon user application processes.
Model: heterogeneous, multiple-instance DOS
Properties: process migration, loadbalancing
Transparency: location, access
Running on:
Date: 1986
Literature:
S. J. Pratt; "The Alchemy Model: A Model for Homogeneous and Heterogeneous Distributed Computing System". ACM Operating System Review, Vol. 20, No.2, April 1986, pp. 25-37.
R. F. Rashid, R. Fitzgerald, G.G. Robertson, L. R. Walmer, R. V. Baron, M. R. Thompson and M. Young
Accent is a communication oriented network operating system kernel for monoprocessors. Interprocess communication over the network is supported by special communication processes. IPC is based on ports, message-oriented and asynchron. The kernel provides ports and processes. A single process is represented by two ports, the kernel- and the data-port. Operations concerning processes are invoked by sending the adequate message to the kernel-port. The SPICE network operating system is implemented as a collection of processes running above the Accent kernel.
Model: client/server, single-instance DOS
Properties: process migration, message passing
Transparency: access, location, failure
Running on: PERQ Systems Corporation PERQ T2, AMD2910
Date: 1981
Literature:
Rashid, R. F. and Robertson, G. G.: "Accent: a communication oriented network operating system kernel". Report CMU-CS-81-123, Department of Computer Science, Carnegie-Mellon University, Pittsburgh, Pennsylvania, USA, April 1981.
Robert Fitzgerald and Richard F. Rashid: "The Integration of Virtual Memory Management and Interprocess Communication in Accent" ACM Transactions on Computer Systems, Vol. 4, No. 2, May 1986, pp. 147-177.
David L. Cohn, Bill Delaney, Karen Tracey, Paul M. Greenawalt, Michael R. Casey and Matthew P. Stevenson
Arcade is a distributed operating system kernel. The principal design objective was to build a system that facilitates seamless interaction among tasks executing on distributed and potentionally heterogeneous processors. The system provides two primary abstractions: tasks and data units. Tasks are the active, executable elements. Data units are passive structured collections of information that are mapped into the address spaces of tasks. The services provided by the ARCADE kernel support the following operations: creation and destruction of tasks and data units, task migration, distributed shared data units, data unit locking and update propagation, and a task synchronization facility based on a programmable logic array analogy.
Model: loosely coupled
Properties: message passing, process migration, atomic transactions
Transparency: location, access, concurrency, replication
Running on: IBM PS/2 80386 connected by a Token Ring network
Date: 1988
Literature:
Karen M. Tracey: "Processor Sharing for Cooperative Multi-Task Applications". PhD. Thesis, University of Notre Dame, Notre Dame, IN April 1991
Karen M. Tracey: "The Design and Implementation of an ARCADE-based Operating System". Master's Thesis, University of Notre Dame, Notre Dame, IN, USA, April 1989
FTP: yogi.pcl.nd.edu
P. Chrysanthis, Krithi Ramamritham and David Stemple
Gutenberg is a distributed object-oriented operating system kernel which facilitates the design and implementation of reliable distributed systems by providing primitives for structuring and controlling process interconnections. In Gutenberg recoverable communicating actions (RCA) serve as units of recovery and consistency. Processes can be decomposed into RCA's which are permitted to communicate among themselves without endangering the consistency of the objects they access. They share many of the traits of other atomic action mechanisms, including hiding the presence of failures by ensuring action atomicity and graceful recovery, and allowing concurrent use of shared information in a reliable, controlled way. They also have several advantages over other approaches to atomic actions: RCA's can communicate with each other thereby forming a recoverable computation; actions in such a computation are not restricted to hierarchical relationships; RCA's allow dependencies to develop between actions dynamically in accordance with their interactions; and RCA's allow processes to control the synchronization of access to user objects, thus providing the opportunity to increase concurrency over standard synchronization techniques by using semantic information.
Model: loosely coupled
Properties: object-oriented, fault-tolerant, atomic transactions
Transparency: access, replication, concurrency, location, failure
Running on:
Date: 1986
Literature:
S. Vinter, K. Ramamritham and D. Stemple: "Recoverable Actions in Gutenberg". IEEE Proceedings of the 6th International Conference on Distributed Computing Systems, pp. 242-249, 1986.
K. Ramamritham, D. Stemple and S. Vinter: "Primitives for Accessing Protected Objects". IEEE ?, pp. 114-121, 1983.
M. Acetta, R. Baron and W. Bolosky
Mach is a process-message system and the successor to Accent which is UNIX-compatible and provides support for multiple processes (threads) in a single address space. Mach is a multiprocessor operating system kernel and environment under development at Carnegie-Mellon University. Mach provides a new foundation for UNIX, development that spans networks of uniprocessors and multiprocessors. New facilities not available in 4.3: separation of the process abstraction into tasks and threads (i.e., memory space protection vs. cheap concurrency), copy-on-read/write virtual memory operations (for memory copy and sharing), memory mapped files, user-provided backing store objects and pagers, capability based network transparent IPC, internal kernel debugger support for transparent remote file access, language support for RPC between tasks in C/pascal/CommonLisp, and a few other tidbits. As of April 1986, all but threads operational and in use on uni- and mulit- processors at CMU. The basic design is to move as much functionality as possible out of the kernel and into user processes, and to have every thing communicate via messages, to allow for use on multiprocessors. This is a descendent of the RIG and Accent systems, and is supposed to take over from the DARPA BSD development.
Model: client-server, single-instance DOS
Properties: micro kernel, message passing, UNIX-compatible, lightweight processes
Transparency: access, location, failure
Running on: NeXT, PC 80386, DEC
Date: 1986
Literature:
M. Acetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and M. Young: "Mach: A new kernel foundation for Unix development." In Proceedings of Summer USENIX 1986 Technical Conference, Atlanta, Georgia, June 1986, pp.93-112.
FTP: wb1.cs.cmu.edu
Joel A. Barlett
The Tandem NonStop System is a fault-tolerant, expandable, and distributed computer system designed expressly for online transaction processing. The operating system provides many of the user services usually associated with medium-size systems: multiprogramming, access to a gigabyte of virtual memory per processes, a file system, and extensive communication facilities. However, it offers these services in a fault tolerant manner on a modular, expandable computer system. The operating system functions are distributed over multiple processes, and as hardware modules are interconnected via redundant buses, the operating system processes communicate via fault-tolerant messages.
Model: multiprocessor, bus-coupled, fully integrated, multiple-instance,
monolithic
Properties: virtual memory, datagram, synchronization, replication, load balancing,
traditional hierarchical, asynchronous message passing, non-blocking
Transparency: failure, replication
Running on: Tandem Computers
Date: 01.01.81 - ?
Literature:
J. A. Barlett: "NonStop Kernel". Proceedings of the 8th Symposium on Operating Systems Principles, Pacific Grove, CA, December 1981, pp. 22-29.
FTP: nic.funet.fi /pub/doc/OS
Richard P. Studdert, John W.G. Buckley, Cormac J. Sreenan and Michael P. Russell
Ogham is a kernel for distributed operating systems. It is based on an object model, with all objects accessed in a location independent fashing using a specialised communication facilitiy. Resource managers are realised as processes that are free to migrate throughout the system. Ogham is designed to allow local area interconnected microcomputers to be used as a computing facility for the investigation of distributed operating systems.
Model: loosely-coupled, workstation, client/server, fully integrated,
homogeneous, multiple-instance, kernelized/micro kernel
Properties: datagram, synchronization, atomic transactions, migration, lightweight,
global naming, asynchronous message passing,
Transparency: location
Running on: Intel 186/51 microcomputers and Ethernet
Date: 01.01.88 - ?
Literature:
Studdert, R. P. and others: "The Architecture of a Distributed Computer System", IEEE, Proceedings of a Workshop on the Future Trends of Distributed Computing Systems in the 1990s, Hong Kong, September 1988, pp. 383--390.
Carnegie-Mellon University, Pittsburgh, USA
Hideyuki Tokuda, Tatsuo Nakajima, and Prithvi Rao
The objective of Real-Time Mach is to develop a real-time version of Mach which can support a predictable real-time computing environment together with a real-time toolset. Because of the high portability of Mach, RT-Mach should be able to provide a common real-time computing environment in various machine architectures including single board computer-based targets. The current version of RT-Mach supports a real-time thread model, integrated real-time thread scheduler, policy/mechanisms separation in the scheduler, real-time synchronisation mechanisms, and memory resident objects.
Model: workstation, homogeneous, shared-memory, multiple-instance,
kernelized/micro kernel, object-oriented
Properties: UNIX-compatible, real-time support, datagram, synchronization,
lightweight, preemptive multitasking, traditional hierarchical,
synchronous message passing,
Transparency: location, access, failure
Running on: Sun-3/60
Date: 01.01.90 - ?
Literature:
Tokuda, H. and others: "Real-Time Mach: Towards a Predictable Real-Time System", Proceedings of USENIX Mach Workshop, Burlington, Vermont, October 1990, pp. 73--82, USENIX Association
Norman Hutchinson and Larry Peterson
The x-kernel is an operating system kernel, that provides an explicit architecture for constructing and composing efficient network protocols. It is configurable, supports multiple address spaces and light-weight processes. The novel aspect of the x-kernel is, that it fully integrates three ingredients: it defines a uniform set of abstractions for encapsulating protocols, it structures the abstractions in a way that makes the most common patterns of interaction efficient, and it supports primitive routines that are applied to common protocol tasks. The entire communication system is embedded in the kernel.
Model: loosely coupled
Properties: message passing, process migration, object-oriented
Transparency:
Running on: Sun-3
Date: 1989
Literature:
Norman C. Hutchinson, Larry L. Peterson, Mark B. Abbott and Sean O'Malley: "RPC in the x-Kernel: evaluating new design techniques". Litchfield Park, Arizona USA, ACM, pp. 91-101, December 1989.
Larry Peterson, Norman Hutchinson, Sean O'Malley and Herman Rao: "The x-Kernel: A Platform for Accessing Internet Resources". Computer, pp. 23-33, May 1990.
Norman Hutchinson and Larry Peterson 3: "The x-Kernel: An Architecture for Implementing Network Protocols". IEEE Computer, pp. 23-33, May 1990.
FTP: cs.arizona.edu
A. Z. Spector and K. R. Swedlow
Camelot is a distributed transaction facility on top of Mach. Camelot is intended to support wide-spread use of transaction processing techniques. Camelot executes on a variety of uni- and multiprocessors on top of the UNIX-compatible, Mach operating system kernel. All of the Camelot layers, except the library routines, are implemented by a collection of Mach processes, which run on every node in a distributed system. Each of these processes is responsible for supporting a particular collection of functions. Processes use Mach-provided threads of control to permit intra-process parallelism. Calls to Camelot are made to the Camelot library, which in turn directs them to a particular Camelot process.
Model: loosely-coupled and multiprocessor, multiple-instance DOS
Properties: atomic transactions, object-oriented, UNIX-compatible, micro kernel,
message passing
Transparency: location, access, concurrency
Running on: IBM RT PC
Date: 1987
Literature:
A.Z. Spector: "Distributed Transaction Processing and the Camelot system". Technical Report CMU-CS-87-100, Department of Computer Science, Carnegie-Mellon University, Pittsburgh, USA
A. Z. Spector, Yakup Paker, Jean-Pierre Banatre and Muslim Bozyigit: "Distributed Transaction Processing and The Camelot System". Berlin 1987, Springer-Verlag, Distributed Operating Systems Theory and Practice, Vol. 28, NATO ASI Series F: Computer and Systems Sciences, 1987, pp.331-354.
"Camelot and Avalon: A Distributed Transaction Facility", Edited by Eppinger, Mummert, Spector, Morgan Kaufmann Publishers, Inc. 1991, ISBN 1-55860-185-6.
M. Ahamad, Marc Pearson, D. Dasgupta, R.J. LeBlanc, C.T. Wilkes, W.F. Appelbe, J. Bernabeu Auban, P. Hutto and M. Yousef Khalidi
Clouds is a fault-tolerant, object based distributed operating system, that integrates a set of nodes into a conceptually centralized system. The system is composed of compute servers, data servers, and user workstations. A compute server is a machine that is available for use as a machine that is available for use as a computational engine. A data server is a machine that functions as a repository for long-lived data. A user workstation is a machine that provides a programming environment for developing applications and an interface with the compute and data servers for executing those applications on the servers. Clouds is a native operating system that runs on top of a native kernel called Ra. Clouds includes transactions and is not UNIX-compatible. Its emphasis is on integrating support for reliable objects in the low level of the system. An object in Clouds is large-grained, since it executes in its own address space. The associated applications programming language is called aeolus.
Model: loosely coupled, integrated, server/client
Properties: fault-tolerant, atomic transactions, object-oriented, micro kernel
Transparency: concurrency, access, location, failure
Running on: Sun-3/50, Sun-3/60
Date: 1983-1987
Literature:
Partha Dasgupta and Leblanc, Jr., Richard J. and William F. Appelbe: "The Clouds Distributed Operating System: Functional Description, Implementation Details and Related Work". In IEEE 8th International C Comference on Distributed Computing Systems, San José, CA (USA), pp. 2-9 June 1988.
McKendry, M. S: "Clouds: a fault-tolerant distributed operating system". In Distributed Processing Technical Committee Newsletter, IEEE, New York.
Dasgupta, P; LeBlanc, R; Spafford, E; Lundstrom, S. F. and Lawrie, D. H: "The Clouds project: design and implementation of a fault-tolerant distributed operating system". IEEE Software, 2(3).
Dasgupta, P; LeBlanc, R. J. and Appelbe, W. F.: "The Clouds distributed operating system". Proceedings of the 8th International Conference on Distributed Computing Systems, San Jose, California, USA, June.
FTP: helios.cc.gatech.edu (130.207.5.20) pub/papers
Horst F. Wedde, Ghasem S. Alijani, Willie G. Brown, Shengdong Chen, Gookhai Kang and Bo-Kyung Kim
The design of Dragon Slayer includes inter-process communication through message passing. It incorporates a dead-lock-free, starvation free process and resource scheduling algorithm which is not dependent on the size of the system. Robustness is achieved by installing a complete copy of Dragon Slayer on each computer in the system. Single image capability is made possible by placing the responsibilities of identifying processes and locating resources on the system processes. Dragon Slayer, the distributed operating system, is really a virtual operating system. It can use an other traditional operating system as its kernel. Services normally performed by the kernel operating system are performed by the Dragon Slayer processes which make system calls to the kernel operating system. Dragon Slayer acts as an interface between the kernel operating systems at each computer.
Model: loosely coupled, client/server, multiple-instance
Properties: WAN support, message passing, object-oriented,
fault-tolerant
Transparency: location, access, replication
Running on: MicroVAX, IBM AIX and VM/IS machines
Date: 1986-1989
Literature:
Horst F. Wedde, Ghasem S. Alijani, Willie G. Brown, Shengdong Chen, Gookhai Kang and Bo-Kyung Kim: "Operating System Support for Adaptive Real-Time Systems in DAGON SLAYER". ACM SIGOPS Vol. 23, No. 3, pp. 126-140.
Carl B. Friedlander and Horst F. Wedde: "Distributed Processing under the Dragon Slayer Operating System". BDM and Wayne State, IEEE Proceedings of the 1986 International Conference on Parallel Processing, August 1986, pp.250-257.
Larry D. Wittie and Andre M. van Tilborg
MICROS is a distributed operating system for the MICRONET network computer. MICROS simultaneously supports many users, each running multicomputer parallel programs. MICROS is intended for control of network computers of thousands of nodes. Each network node is controlled by a private copy of the MICROS kernel processes written in Concurrent Pascal. Resource management tasks are distributed over the network in a control hierarchy. Management and user tasks are sequential Pascal programs dynamically loaded into the nodes.Whether in the same or different nodes, tasks communicate via a uniform message passing system.
Model: bus-coupled multiprocessor
Properties: message passing
Transparency: access, location
Running on: LSI-11, MC68000
Date: 1978
Literature:
Larry D. Wittie and Fanyuan Ma: "MICROS, A Distributed Operating System for MICRONET, A Reconfigurable Network Computer". IEEE Transactions on Computers, VC29 N12, Dec. 1980, pp. 1133-1144.
Larry D. Wittie and Fanyuan Ma: "TCP/IP communication sub-system in MICROS". Proceedings Second International Conference on Computers and Applications, IEEE, 1987, pp 469-474.
IEEE
D. Tsay and M. Liu
MIKE (Multicomputer Intergrator Kernel) provides system-transport operations for users and maintains cooperative autonomy among local hosts. Its a framework as a modul of a network operating system for use in distributed systems in general and for use in Distributed Double-Loop Computer Network particular. MIKE is based on the object model and a novel task concept, using message passing as an underlying semantic structure. A layered protocol is provided for the ditributed system kernel to support NOS. This approach provides a flexible organisation in which system-transparent resource sharing and distributed computing can evolve in a modular fashion.
Model: multi-processor, object-oriented
Properties: asynchronous message passing, heterogeneous, modular
Transparency:
Running on:
Date: 1982 - ?
Literature
D. Tsay and M. Liu: "MIKE: A Network Operating System for the Distributed Double-Loop Computer Network". IEEE Transaktions on Software Engineering, Vol. SE-9, No. 2, March 1983.
M.T. Liu et al: "System design of the Distributed Double Loop Computer Network (DDLCN)", in Proc. 1st Int. Conf.Distributed Computer System, October 1979, pp. 95-105.
D.P. Tsay: "MIKE: A Network Operating System for distributed Double Loop Computer Network", Ph.D. dissertation, Dep.Computer Information Science, Ohio State University, Columbus, June 1981.
Anita K. Jones, Robert J. Chansler, Ivor Durham, Karsten Schwans and Steven R. Vegdahl
StarOS is a message-based, object-oriented multiprocessor operating system, specially designed to support task forces, large collections of concurrently executing processes that cooperate to accomplish a single purpose. All information in StarOS is encoded and stored in objects. Objects are typed; the type of an object determines the behavior of the object. All objects are distinct and unique. To access an object to extract information stored in it, or to alter the object, a process invokes some function defined on the object. To be successful in making such an access a process must possess a capability or protected address for the object.
Model: multiprocessor
Properties: object-oriented, message passing, lightweight processes, micro kernel,
capabilities
Transparency: location, access
Running on: CM* multi-microprocessor computer
Date: 1977
Literature:
Anita K. Jones, Robert J. Chansler, Ivor Durham, Karsten Schwans and Steven R. Vegdahl: "StarOS, a Multiprocessor Operating System for the Support of Task Forces". ACM Proceedings of 7th Symposium on Operating System Principles, pp. 117-127, Dec. 1979.
Kazuhiko KATO, Shigekazu INOHARA, Atsunobu NARITA, Shigeru CHIBA and Takashi MASUDA
The XERO distributed operating system aims at providing an open distributed processing environment in which logical information structures are preserved against geographical distribution, hardware and software architectural distribution, and temporal distribution. A programming model at the operating system level is suggested which supports multicontexts and multithreads in a virtual address space. XERO supports a complex object file system to preserve data types in a file system and to develop distributed file systems systematically.
Model: workstation, homogeneous, kernelized/micro kernel
Properties: lightweigth processes, virtual memory, datagram, lightweight-processes,
migration, traditional hierarchical naming, RPC
Transparency: location, access
Running on: SONY News workstations
Date:
Literature:
Kazuhiko KATO, Shigekazu INOHARA, Atsunobu NARITA, Shigeru CHIBA and Takashi MASUDA: "Design of the XERO Open Distributed Operating System". Department of Information Science, Faculty of Science, University of Tokyo.
Daniel T. Chang
CORAL is an object-oriented programming system that permits the construction and execution of sequential, parallel and distributed applications in a transparent manner. It is based on a concurrent object-oriented model of computing in which concurrent objects may execute sequentially in a single processor, in parallel over shared memory mutiprocessors, or distributed over multicomputer networks. In addition, methods within an object may execute in parallel over shared-memory multiprocessors.
Model: loosely-coupled and shared memory multiprocessors
Properties: object-oriented, message passing, atomic transactions
Transparency: location, access, concurrency
Running on: AIX/PS2, AIX/370
Date: 1990
Literature:
Daniel T. Chang: "CORAL: A Concurrent Object-Oriented System for Constructing and Executing Sequential, Parallel and Distributed Applications". ACM Operating Systems Review, pp. 26-30.
Jeffery S. Chase, Franz G. Amador, Edward D. Lazowska, Henry M. Levy and Richard J. Littlefield
Amber is a programing system that permits a single application program to use a homogeneous network of computers in a uniform way, making the network appear to the application as an integrated multiprocessor. Amber is designed for high performance in the case where each node in the network is shared-memory multiprocessor. Amber shows that support for loosely-coupled multiprocessing can be efficiently realized using an object-based programming model. Amber programs execute in a uniform network-wide object space, with memory coherence maintained at the object level. Careful data replacement and consistency control are essential for reducing communication overhead in a loosely-coupled system. Amber programmers use object migration primitives to control the location of data and processing. Amber is a follow-up to the Emerald project. Amber is implemented on top of the Topaz operating system.
Model: loosely-coupled multiprocessor
Properties: object-oriented, process migration, lightweight processes
Transparency: location, access, concurrency, migration
Running on: DEC Firefly
Date: 1989
Literature:
Jeffery S. Chase, Franz G. Amador, Edward D. Lazowska, Henry M. Levy and Richard J. Littlefield: "The Amber System: Parallel Programming on a Network of Multiprocessors". Proc. Twelfth ACM Symposium on Operating Systems, Operating Systems Review, Vol. 23, No.5, December 1989, pp.147-158.
Barbara Liskov, Dorothy Curtis, Paul Johnson and Robert Scheifler
Argus is a distributed object-oriented programming language and operating system, which has been developed to support the implementation and execution of distributed programs. A program in Argus runs on one or more nodes. Each node is a computer with one or more processors and one or more levels of memory. Argus was designed to support programs like the banking system. To capture the object-oriented nature of such programs, it provides a special kind of objects, called a guardian, which implements a number of procedures that are run in response to remote requests. To solve the problems of concurrency and failures, Argus allows computations to run as atomic transactions.
Model: server/client
Properties: fault-tolerant, atomic transactions, object-oriented
Transparency: access, location, concurrency, failure
Running on: MicroVAX-II
Date: 1988
Literature:
Barbara Liskov, Dorothy Curtis, Paul Johnson and Robert Scheifler: "Implementation of Argus". Austin TX (USA) ACM pp. 111-122, November 1987.
Barbara Liskov: "The Argus language and system". ln Lecture Notes in Computer Science, 190, Springer-Verlag, Berlin, pp. 344-430.
S. K. Shrivastava, G. N. Dixon and G. D. Parrington
Arjuna is an object-oriented programming system that provides a set of tools for the construction of fault-tolerant distributed applications. A prototype version written in C++ has been designed and implemented to run on a collection of UNIX workstations connected by Ethernet. Arjuna provides nested atomic transactions for structuring application programs. Other features of this programming system are multicast remote procedure calls, process groups, commit processing and type-inheritance.
Model: loosely coupled
Properties: object-oriented, fault-tolerant, UNIX-compatible, atomic transactions
Transparency: location, access
Running on: Sun-4, Transputer (Helios)
Date: 1990
Literature:
S. K. Shrivastava, G. N. Dixon and G. D. Parrington: "An Overview of Arjuna: A Programming System for Reliable Distributed Computing". Newcastle-upon-Tyne, England, November 1989.
G. N. Dixon, G. D. Parrington, S. K. Shrivastava and S. M. Wheater: "The Treatment of Persistent Objects in Arjuna". Nottingham (GB), July 1989.
G. N. Dixon, S. K. Shrivastava and G. D. Parrington: "Managing Persistent Objects in Arjuna: A System for Reliable Distributed Computing". Appin, Scotland 1987, Proceedings of the Workshop on Persistent Object Systems, their Design, Implementation and Use, August 1987.
FTP: ftp.cse.ucsc.edu /pub/tcos
D. Wybranietz and Peter Buhler
COIN is a model for object-oriented programming with special emphasis on concurrent and distributed systems. The central goal of its development was to incorporate aspects of software design and visualization into the object-oriented paradigm. The distinguishing characteristics of COIN are hierarchical object structures determining the visibility of objects, multiple explicit object interfaces, explicit and dynamic binding of interface operations to operation implementations and generation of structures consisting of several objects and their interconnections as an atomic action.
Model: client/server
Properties: object-oriented, atomic transactions, message passing
Transparency: concurrency, location, access
Running on: Sun-4
Date: 1991
Literature:
Peter Buhler: "COIN-An Approach for Parallel and Distributed Programming". Universität Kaiserslautern, 1991.
Peter Buhler: "The COIN Programming Environment for Distributed Systems". Proc. of the Second IEEE Workshop on Experimental Distributed Systems, Huntsville, Alabama, 1990, pp. 70-74.
Peter Buhler: "The COIN Model for Concurrent Computation and its Implementation". Microprocessing and Microprogramming 30, North Holland, 1990, pp. 577-584.
Jeff Kramer, Jeff Magee and Morris Sloman
The Conic environment provides a language-based approach to the building of distributed systems which combines the simplicity and safety of a language approach with the flexibility and accessibility of an operating systems approach. Conic is specially designed to build dynamically reconfigurable distributed systems. As such it has separate programming and configuration languages, based on Pascal. It provides a comprehensive set of tools for program compilation, configuration, debugging and execution in a distributed environment. The environment is particularly strong in its configuration facilities. A serparate configuration language is employed to specify the configuration of software components into logical nodes. This provides a concise configuration description and facilitates the reuse of program components in different configurations. Applications are constructed as sets of one or more interconnected logical nodes. Arbitrary, incremental change is supported by dynamic configuration, the capability to dynamically create, interconnect, and control logical nodes. In addition the system provides user transparent datatype transformation between heterogeneous processors. Applications may be run on a mixed set of interconnected computers running the UNIX operating system and on bare target machines with no resident operating system.
Model: heterogeneous
Properties: UNIX-compatible
Transparency: access, location
Running on: Sun-3, MC68000, VAX, PDP-11
Date: 1989
Literature:
Jeff Magee, Jeff Kramer and Morris Sloman: "Constructing Distributed Systems in Conic". IEEE Transactions on Software Engineering Vol. 15, No. 6, June 1989, pp. 663-675.
Jeff Kramer and Jeff Magee: "The Evolving Philosophers Problem: Dynamic Change Management". IEEE Transactions on Software Engineering Vol. 16, No. 11, November 1990.
FTP: gummo.doc.ic.ac.uk
Marc Shapiro, Mesaac Makpangou, Sabine Habert and Roger Lea
COOL is an efficient object-oriented support layer built directly on the Chorus Micro-Kernel. COOL can be seen as two distinct layers; the COOL base mechanisms which collectively provide a set of object support abstractions; and the COOL run-time system which specializes the system interface to support a specific object model. COOL is an object-oriented parallel language derived from C++ by adding constructs to specify concurrent execution. The language design provides facilities for creating parallelism, performing synchronization, and communicating. The parallel construct is parallel functions that execute asynchronously. Synchronization support includes mutex functions and future types. A shared-memory model is assumed for parallel execution, and all communication is through shared-memory. The parallel programming model of COOL has proved useful in several small programs that we have attempted.
Model: shared memory
Properties: UNIX-compatible, process migration, message passing,
object-oriented
Transparency: location, access, concurrency
Running on: SM90 multi-microprocessor
Date: 1989-1990
Literature:
Sabine Habert, Laurence Mosseri and Vadim Abrossimov: "COOL: Kernel Support for Object-Oriented Environments". Ottawa (Canada), ACM, pp. 269-277, October 1990.
Rohit Chandra, Anoop Gupta and John L. Hennessy: "Cool: A Language For Parallel Programming". Stanford, CA 1989, Computer Systems Lab, Stanford University, CSL-TR-89-396, October 1989.
Sabine Habert: "COOL: Kernel support for object oriented environments". Ottowa, Canada 1990 Chorus systèmes, Procs of OOPSLA'90, 1990, CS-TR-90-50.
Jean Dollimore, J. R. Nicol, G. S. Blair and W. D. Shepherd
COSMOS is a distributed programming environment that supports structured group working. In COSMOS a Communication Structure (CS) is designed to be a system of rules which characterize the form of communication activity. The main components of the Cosmos system are an object server, a name mapping service and the Cosmos information service. Further there are a structure interpreter and a message delivery service. The message delivery service has two roles, passing incoming messages to local users and sending outgoing messages to local and remote users. The structure interpreter is a component that interprets structure definitions for activities and enables users to perform the appropriate operations in activities. The name mapping service maps text names onto binary patterns and may be used to build hierarchic naming structures. The object server provides a means of storing and retrieving objects with unique identifiers.
Model: client/server, loosely-coupled
Properties: object-oriented, message passing, UNIX-compatible, atomic transactions
Transparency: access, replication, concurrency, location, failure
Running on: Sun-3
Date: 1987
Literature:
Jean Dollimore: "The Design of an Object Server as a Storage Module for the Cosmos Messaging System". North-Holland Vienna (Austria), COST 11ter Action, Proc. of the EUTECO'88 Conf., Commission of the European Communities, pp. 171-183, April 1988.
J. R. Nicol, G. S. Blair and W. D. Shepherd: "A Tailored Kernel Design for a Distributed Operating System". Lancaster, England, Department of Computing, University of Lancaster, Internal Report CS-DC-3-86, 1985.
J. R. Nicol: "Operating System Design for Distributed Programming Environment". University of Lancaster, Ph. D. Thesis, October 1986.
G. S. Blair, J. R. Nicol and J. Walpole: "An Overview of the Cosmos Distributed Programming Environment Project". Lancaster, England, Department of Computing, University of Lancaster, Internal Report CS-DC-4-87, 1987.
Klaus-Peter Löhr and Lutz Nentwig
DAPHNE is a system of tools and run-time support routines that allow programs to be broken into parts for distributed execution on different nodes of a heterogeneous computer network. This approach to distributed programming is both simple and general. It serves as a natural basis for classical network services such as remote file access or remote login while the same time allowing arbitrary distributed applications to be written in a standard programming language. The pivot of DAPHNE is a remote procedure call mechanism that is specially adapted to a heterogeneous environment, notably heterogeneous systems software. The current language context of DAPHNE is Modula-2.
Model: heterogeneous, server/client, loosely-coupled
Properties: UNIX-compatible
Transparency: location, access
Running on: networked UNIX and MS-DOS systems
Date: 1988
Literature:
Klaus-Peter Löhr and Lutz Nentwig: "DAPHNE: Support for Distributed Computing in Heterogeneous Environments", Proceedings European Workshop on Progress in Distributed Operating Systems and Distributed Systems Management, Berlin, Springer-Verlag, April 1989.
Klaus-Peter Löhr, Joachim Müller and Lutz Nentwig: "DAPHNE: Support for Distributed Applications Programming in Heterogeneous Computer Networks", IEEE, Proceedings of the 8th International Conference on Distributed Computing System, San Jose, 1988.
Irmtraut and Klaus D. Günther
The DISCO system is intended to support applications programmers and users of distributed office applications in an inhomogenous hardware and operating system environment. DISCO will provide automatic crash recovery; "rarely blocking" distributed transactions; a terminal-independent, syntax-directed, forms-oriented terminal interface; and flexible facilities for re-routing and delegating sub-tasks of computer-aided office procedures. Inter-process communication is based on a largely unified transport service interface. A major goal of the DISCO design has been to acheive a very high degree of portability of all system components and application programs.
Model: loosely-coupled, heterogenous
Properties: system-supported restart after crashes, electronic signatures
Transparency:
Running on:
Date: 1986
Literature:
Irmtraut and Klaus D. Günther: "DISCO: A Programming and Run-time Support System for Distributed Communication-Oriented Office Applications", North-Holland Vienna (Austria), COST 11ter Action, Proc. of the EUTECO'88 Conf., Commission of the European Communities, pp. 761-773, April 1988.
Klaus D. Günther: "DISCO-A Programming and Run Time Environment for Distributed Cooperative Office Applications", Proceedings of the ERCIM Workshops INESC, Lisabon, Portugal, Nov. 14-15, 1991.
Wim Bronnenberg and Eddy Odijk
DOOM is an dezentralized object-oriented machine and operating system. The main target of the DOOM OS is the efficient execution of POOL programs on the DOOM architecture. This task consists of a number of related aspects, such as resource management, process management and communication handling. An interesting feature is the garbage collection which is an on-the-fly mark and sweep algorithm.
Model: multiprocessor, object-oriented, fully integrated, homogeneous, tightly-
coupled
Properties: object-oriented, load balancing, point-to-point, synchronous message
passing
Transparency: location, access
Running on: DOOM Multiprocessor Architecture
Date: 01.01.88 - ?
Literature:
Wim Bronnenberg and Eddy Odijk: "DOOM: An Object-Oriented Approach to Parallel Computing". St. Petersberg, FL Third International Conference on Supercomputing (ICS '88), Proceeding Supercomputing '88: Technology Assessment, Industrial Supercomputer Outlooks, European Supercomputing Accomplishments, and Performance & Computations, Vol. 2, pp.271-281.
Wim Bronnenberg, Eddy Odijk, M. Rem and J. -C. Syre: "POOL and DOOM". Eindhoven, The Netherlands 1989 Springer-Verlag, PARLE '89 Parallel Architectures and Languages Europe Vol I: Parallel Architectures & Vol. II: Parallel Languages,Vol. 365 & 366, Lecture Notes in Computer Science, June 1989.
J. K. Annot: "A Deadlock Free and Starvation Free Network of Packet Switching Communication Processors", Parallel Computing, Vol. 9, No. 2, January 1989, pp. 147-162
W. Dann and G. Dohmen: "Specifying Distributed Computer Architectures an AADL", Parallel Computing, Vol. 9, No. 2, January 1989, pp. 193-211.
Norman C, Hutchinson, Rajendra K. Raj, Andrew P. Black, Henry M. Levy, Eric Jul, E.D. Lazowska, and G.T. Almes
Emerald is a distributed object-based language and system, designed to simplify the construction of distributed programs. An explicit goal of Emerald is object mobility; objects in Emerald can freely move within the system to take advantage of distribution and dynamically changing environments. Its main innovation to Eden is that it presents a unified view of objects regardless of their size. This is called fine-grained mobility, because Emerald objects can be small data objects as well as objects with processes. Thus the unit of mobility can be much smaller than in process migration systems which typically move entire address spaces. Object mobility in Emerald subsumes both process migration and data transfer.
Model: loosely coupled, integrated
Properties: object-oriented, process migration
Transparency: access, location, migration
Running on: MicoVAX II, Sun-3
Date: 1986-1987
Literature:
Norman C. Hutchinson: "Emerald: An Object-Based Language for Distributed Programming". Department of Computer Science, University of Washington, Seattle, WA (USA), January 1987.
Rajendra K. Raj, Ewan Tempero, Henry M. Levy, Norman C. Hutchinson and Andrew P. Black: "The Emerald Approach to Programming". Department of Computer Science, University of Washington, Seattle, WA (USA), November 1988.
E. Jul, H. Levy, N. Hutchinson and A. Black: "Fine-grained mobility in the Emerald system". Proc. of the Eleventh ACM Symposium on Operating System Principles, November 1987, pp. 105-106.
T. Kindberg, A.V. Sahiner and Y. Parker
Equus is a programming model and environment for computations consisting of communicating processes which can be reconfigured at run-time. These reconfigurable distributed computations, RDCs, run at the nodes of a distributed memory multicomputer. The model is realized as a set of calls from C language. The system is based on a small kernel, that supports the dynamic creation, migration and destruction of processes, and the reconfiguration of communications interfaces between them.
Model: loosely coupled
Properties: micro kernel, message passing, process migration
Transparency: access, location, migration
Running on: Sun-3
Date:
Literature:
T. Kindberg, A.V. Sahiner and Y. Parker: "Equus: an Environment for Reconfigurable Distributed Computations". Department of Computer Science, Queen Mary and Westfield College, London
Kenneth P. Birman
ISIS provides a toolkit for distributed and fault-tolerant programming. It runs on top of UNIX-systems and no kernel changes are needed to support ISIS. The essential premise is, that building fault-tolerant distributed systems is hard so high-level support and automatic generation from fault-intolerant systems are needed. ISIS is also useful of building a certain type of distributed real-time systems.
Model: loosely coupled
Properties: fault-tolerant, UNIX-compatible, lightweight processes, atomic transactions,
real-time support
Transparency: location, access, replication, concurrency
Running on: SUN, DEC, AIX, HP, GOULD, AUX
Date: 1985-1991
Literature:
Birman, K. P.: "ISIS: a system for fault-tolerant distributed computing". Report 86 744, Department of Computer Science, Cornell University, Ithaca, New York, USA, April 1986
Birman, K. P; Skeen, D; Abbadi, A. El; Dietrich, W. C. and Raeuchle, T: "ISIS: an environment for constructing fault-tolerant distributed systems". Report TR 83-552, Department of Computer Science, Cornell University, Ithaca, New York, USA, May 1983
Birman K.: "Replication and Fault-Tolerance in the ISIS System". 10th ACM Symposium on Operating Systems Principles, December 1985, pp. 79-86.
FTP: ftp.cs.cornell.edu
cu-arpa.cs.cornell.edu
D. Wybranietz and P. Buhler
The LADY programming environment has been developed to support the design, implementation, testing, debugging and monitoring of distributed systems with special focus on operating systems. In LADY a distributed system is viewed as a collection of cooperating objects connected though typed interfaces. The language offers dynamic modifications of the program structure such as generation and deletion of objects and their interconnections as well as migration and checkpointing of objects. Further Features include the extensibility of programs and recursive definition of objects.
Model: loosely-coupled
Properties: process migration, object-oriented, message passing, lightweight processes
Transparency: location, access, concurrency
Running on: networked MC68000-based systems
Date: 1980 - 1985
Literature:
D. Wybranietz and P. Buhler: "The LADY Programming Environment for Distributed Operating Systems". PARLE '89 Proceedings, Springer Verlag, LNCS 365, pp. 100-117.
Mark Sullivan and David Anderson
Marionette is an software package for distributed parallel programming in an environment of networked heterogeneous computer systems. It uses a master/slave model in which otherwise sequential application programs can invoke worker operations and context operations asynchronously. The master and slaves also interact through shared data structures that can be modified by the master. Shared data structure and context operation mechanisms allow efficient read-only sharing of data structures by slaves. The Marionette run-time system is a heterogeneous RPC package. It also maintains the consistency of shared data structures, recovers transparency from slave failure and assigns operations to slaves. The Marionette includes tools for debugging automated compilation of program binaries for multiple architectures and distributing binaries to remote file systems.
Model: client/server, loosely-coupled, heterogeneous
Properties: UNIX-compatible, fault-tolerant
Transparency: failure, location, access
Running on: Sun-3/50
Date: 1989
Literature:
Mark Sullivan and David Anderson: "Marionette: a System for Parallel Distributed Programming Using a Master/Slave Model". IEEE Procs. of the 9th Int. Conf. on Distributed Computing Systems, pp.181-188, June 1989.
Distributed Programming Environment
IBM Hawthorne, USA
Robert E. Strom and Shaula Yemini
NIL supports the construction of distributed software systems:
1. A process model in which no pointers or shared data are visible
2. Interprocess communication via synchronous and asynchronous message passing
3. Compile time typestate checking, guaranteeing module isolation and correct finalisation of
data
4. Dynamic binding of statically typed ports under the control of capabilities
Model: kernelized/micro kernel
Properties: asynchronous message passing, synchronous message passing, channels
Transparency: access
Running on:
Date: 01.01.1983
Literature
Robert E. Strom and Shaula Yemini: "NIL: An Integrated Language and System for Distributed Programming". ACM, Proceedings of the SIGPLAN '83 Symposium on Programming Issues in Software Systems, June 1983.
E. Strom: "Mechanism for Compile-Time Enforcement of Security", Tenth Symposium on Principles of Programming Languages, Austin, January 1983.
R. Bagrodia and K.M. Chandy
CMAY is a general purpose distributed programming language derived form FORTRAN. CMAY was designed by incorporating two basic notations - entities and messages in a sequential programming language. The implementation supports a library facility. CMAY programs may include routines and entities from the CMAY library. A versatile trace library is also provided. This facility may be used to trace messages exchanged between entities.
Model: mini-computer, homogeneous, loosely-coupled, kernelized/micro kernel
Properties: traditional hierarchical naming, asynchronous message passing
Transparency:
Running on: VAX 11/750, IBM PC
Date: 1984 - ?
Literature
R. Bagrodia and K.M. Chandy: "A Micro-Kernel for Distributed Applications", IEEE CH2149-3/85, pp. 140-149, 1985.
J.A. Feldmann: "High Level Programming For Distributed Computing", Comm. ACM, Vol.22, No. 6 , June 1979, pp. 353-367.
G.R. Andrews: "Synchronizing Ressources", ACM Trans. Programming Language Systems, Vol. 3, No.4, Oct.1981, pp. 405-430 .
R. Bagrodia, K.M. Chandy, and J. Mista: "A Message Based Approach to Discret Event Simulation", Report TR LCS - 8403, Dept. of Computer Sciense, University of Texas at Austin, May 1984.
Shaula A. Yemini, German S. Goldszmidt and Alexander D. Stoyenko
Concert is a high-level-language-based programming system for heterogeneous distributed systems. The Concert model introduces a small set of language extensions into conventional procedural languages. These language extensions support a cooperative peer process model which addresses in the distributed environment the same issues addressed by language semantics in the conventional environment. The Concert implementation provides layered support for these language extensions, bridging a different source of heterogeneity at each layer.
Model: heterogeneous, loosely coupled
Properties: UNIX-compatible, process migration, fault-tolerant
Transparency: access, location, failure
Running on: AIX, OS/2 on PS/2
Date: 1989
Literature:
S. A. Yemini, G. Goldszmidt, A. Stoyenko, Y. Wei and L. Beeck: "Concert: A High-Level-Language Approach to Heterogeneous Distributed Systems". IEEE: The Ninth International Conference on Distributed Computing Systems, pp. 162-171, June 1989.
Yi-Hsiu Wei, Alexander D. Stoyenko and German S. Goldszmidt: "Data Conversion and Stub Generation in Concert RPC System". RC15973, 1990.
Chung-Ming Li and Ming T. Liu
Dislang is a distributed programming language for use in distributed computing sytems and computer networks. A language concept, called Communicating Distributed Process (CDP), is proposed to provide language constructs for handling inherent features in distributed environments. Such as global operations, communication time-out, multi-process communication, atomic operations etc. A CDP consists of four components and all information about process communication and data distribution is collected together and is specified in a component, called Communicatior. Operation types are also used in CDP to specify operations in an abstract way to achieve communication/distribution abstraction.
Model: workstation, object-oriented, modular, loosely-coupled
Properties: multicast, Multiple Communications Primitive, atomic operations
Transparency:
Running on:
Date: 1981 - ?
Literature
C.-M. Li and M.T. Liu: "DISLANG: A Distributed Programming Language/System". Software Engineering for Distributed Systems, Paris, France 1981 IEEE 2nd International Conference on Distributed Computing Systems, April 1981, pp.162-172.
C.-M. Li and M.T. Liu: "Communicating Distributed Processes: A Language Concept for Distributed Programming in Local Area Networks," Proc. IFIP International workshop on Local-Area Computer Networks, North-Holland, August 1980.
C.-M. Li and M.T. Liu: "Minimum-Delay Process Communication: A Language Concept for Highly-Parallel Distributed Programming", Digest of Papers, COMPCON 1981.
C.-M. Li: "Communicating Distributed Processes: A Programming Language Concept for Distributed Systems," Ph.D. dissertation, The Ohio State University, Department of Computer and Information Science, March 1981.
B. Hindel
HERAKLIT is a general purpose object-oriented programming language with a hierarchic type concept. It is designed for efficient development and maintenance of software for distributed systems. Some ideas of SIMULA, CLU and SMALLTALK are combined in HERAKLIT. The syntax of HERAKLIT is close to MODULA-2. A special feature of HERAKLIT is the ability to exchange modules (objects) at run-time without stopping the entire program. A HERAKLIT object can be used for data and program abstraction. An object can contain data entries and algorithms that allow to refer and alter these entries. The data entries and algorithms of an object are both called its components. HERAKLIT distinguishes public and private components. Private Components are only for object internal representations and duties, while the public components can also be used by other objects.
Model: shared memory
Properties: process migration, object-oriented, UNIX-compatible
Transparency:
Running on:
Date: 1989
Literature:
B. Hindel: "An Object-Oriented Programming Language for Distributed Systems: Heraklit", 1989, Proc. of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming ACM SIGPLAN Notices, Vol. 24, No.4, April 1989, pp.114-116.
Michael L. Scott and Raphael A. Finkel
LYNX is a message-based distributed programming language with novel facilities for communication between processes and for management of context within processes. LYNX was first implemented on the Crystal multicomputer at the University of Wisconsin. It has subsequently been ported to the Butterfly Parallel Processor at the University of Rochester. A programming language can provide much better support for interprocess communication than a library package can. Most message-passing languages limit this support to communication between the pieces of a single program, but this need not be the case. Lynx facilitates convenient, typesafe message-passing not only within applications, but also between applications, and among distributed collections of servers. Specifically, it addresses issues of compiler statelessness, late binding, and protection that allow run-time interaction between processes that were developed independently and that do not trust each other. Implementation experience with Lynx has yielded important insights into the relationship between distributed operating systems and language run-time support packages, and into the inherent costs of high-level message-passing semantics.
Model: multiprocessor, homogeneous
Properties: datagram/messages, synchronization, heavyweight processes, RPC
Transparency:
Running on: Crystal multicomputer, Butterfly Parallel Processor
Date: 01.01.84 - ?
Literature:
Michael L. Scott; Raphael A. Finkel; "LYNX: A dynamic distributed programming language". IEEE Proceedings of the 1984 International Conference on Parallel Processing, August 1984, pp. 395-401.
M. L. Scott; "LYNX Reference Manual"; Computer Science Department, University of Rochester, BPR 7, August 1986.
Steven S. Popovich, Shyhtsum F. Wu, and Gail E. Kaiser
The Meld object-oriented programming language supports classes, strong tying, active values, multiple inheritance, and separate compilation of modular units called features. These facilities were developed for an early version of Meld, without persistence, concurrency or distribution. Meld allows any class to be declared persistent, and instances of persistent classes are stored in a database. Access to persistent and/or remote objects are stored locally or remotely, transiently or persistently. Meld creates new threads of control for both asynchronous messages and synchronous procedure calls. Synchronous calls are implemented internally by an asynchronous message pass followed immediately by a statement waiting for the return message. Multiple threads may execute concurrently in the same object. All message passing outside of the local process goes through the name server, which looks up the object identifier and forwards the message to the proper host, where it is delivered to the destination process by the remote server.
Model: client/server, object-oriented
Properties: synchronization, atomic transactions, message passing, persistent
objects, name server, synchronous and asynchronous message passing,
RPC
Transparency: concurrency, control, location
Running on:
Date: 1992-?
Literature
Steven S. Popovich, Shyhtsum F. Wu, and Gail E. Kaiser: "An Object-Based Approach to Implementing Distributed Concurrency Control", IEEE Computer Society Press, Proceedings of the 11th International Conference on Distributed Computing Systems, Arlington, Texas, USA, May 20-24, 1991, pp. 65-72.
P.A. Bernstein, Vassos Hadzilacos, and N. Goodman: "Concurrency Control and Recovery in Database Systems", Addison-Wesley, Reading MA, 1987.
G.E. Kaiser and D.Garlan: "Melding Software Systems from Reusable Building Blocks", IEEE Software 4(4): 17-24, July, 1987.
Gregory R. Andrews and Ronald A. Olsson
Synchronizing Resources (SR), a distributed programming language contains code to perform context switching on a number of machines. The language supports many processes that execute in parallel. SR allows an entire software system that controls a potentially large collection of processes to be programmed as an integrated set of software modules. The key language mechanisms are resources, operations and input statements. The language supports separate compilation, type abstraction, and dynamic communication links; it also contains novel treatments of arrays and procedures. SR also supports several IPC mechanisms but no process migration. SR does not include language constructs for the support of atomicity.
Model: loosely-coupled and shared memory
Properties: UNIX-compatible, message passing, capabilities
Transparency: location, access, concurrency
Running on: PDP-11/70
Date: 1981
Literature:
Gregory R. Andrews: "The Distributed Programming Language SR - Mechanisms, Design and Implementation" 1982, Software Practice and Experience, Vol. 12, No. 8, pp. 719-753, Aug. 1982.
Gregory R. Andrews and Ronald A. Olsson: "Report on the Distributed Programming Language SR", Tucson, Arizona, University of Arizona, TR 85-23, November 27, 1985.
FTP: cs.arizona.edu sr/rts
Dilip D. Kandlur, Daniel L. Kiskis, and Kang G. Shin
HARTOS is the distributed real-time operating system for the HARTS architecture. An important feature of HARTS is the use of an intelligent network processor to handle many of the functions relating to communications. Interesting research issues in the design of HARTOS are support of replicated processes, the use of network processors, real-time communication and fault-tolerant routing. The preliminary version of Hartos utilizes the pSOS uniprocessor real-time os kernel and extends its facilities to a multi-processor, multi-computer environment.
Model: loosely-coupled, multiple instance
Properties: real-time support, fault-tolerant, message passing
Transparency: replication, failure, access, location
Running on: Ironics Performer-32 (VME-Bus and 1-3 MC68020)
Date: 1987
Literature:
Dilip D. Kandlur, Daniel L. Kiskis and Kang G. Shin: "HARTOS: A Distributed Real-Time Operating System". ACM SIGOPS Vol. 23 No. 3, pp. 72-89.
W.E. Boebert, W.R. Franta, D.R. Jensen and R.Y. Kain
The HXDP executive project was established by the Honeywell Systems and Research Center to produce a software Executive for the HXDP systems. HXDP is a set of loosely-coupled processor-memory pairs intended for research in distributed computer systems for real-time control applications. As the primary memory address spaces are disjoint in HXDP, all interprocessor communication is passed as messages; message handling is facilitated by special functionality in the interconnection hardware. The goal of the executive project was to investigate problems of distributed real-time control software as well as to implement a usable experimental system. The software product was a set of kernel functions to support both applications software and advanced Executive functionality.
Model: loosely coupled
Properties: real-time support, message passing, fault-tolerant
Transparency:
Running on: Honeywell HXDP
Date: 1978
Literature:
Jensen D.R.: "The Honneywell experimental distributed processor-An overview of its objective, philosophy and architectural facilities". IEEE Computer 11 (1), January 1978, pp. 28-38.
W. E. Boebert; W. R. Franta; E. D. Jensen; R. Y. Kain: "Kernel Primitives of the HXDP Executive". IEEE Computer Software and Applications Conference (COMPSAC78), November 1978, pp. 595-599.
H. Kopetz, A. Damm, Ch. Koza, M. Mulazzani, W. Schwabl, Ch. Senft and R. Zainlinger
Mars is a distributed fault-tolerant real-time operating system architecture for process control applications. It is intended to be used in industrial real time systems where hard deadlines are imposed by the controlled environment. One characteristic feature of MARS distinguishing it from other distributed systems is the completely deterministic behavior of the system even under peak load conditions. Specialities are the exact synchronization of time (less than equal 10e-6 seconds), the guaranteed deadlines and the simple replacement of failed components. Mars uses a transaction model to describe the activities of a real-time system. Communication among tasks and components is realized by the exchange of state-messages with a valid time. All MARS components have access to a common global time base, the system time, with known synchronization accuracy.
Model: loosely-coupled
Properties: fault-tolerant, real-time support, atomic transactions, message passing
Transparency: location, access, failure
Running on: MC68000
Date: 1988
Literature:
H. Kopetz, A. Damm, Ch. Koza, M. Mulazzani, W. Schwabl, Ch. Senft and R. Zainlinger: "Distributed Fault-Tolerant Real-Time Systems: The MARS Approach". IEEE Micro, pp. 25-40, Feb. 1989.
A. Damm, J. Reisinger, W. Schwabl and H. Kopetz: "The Real-Time Operating System of MARS". ACM SIGOPS, Vol. 23 No. 3, pp. 72-89.
FTP: ftp.vmars.tuwien.ac.at pub/papers
Keith Marzullo, Mark Wood
Many distributed applications can be cast as a reactive system, where a reactive system consists of an instrumented program that is monitored and controlled by an input-driven control program. Examples of non-real-time reactive systems include monitoring and debugging systems, tool integration services, and network and distributed application managers. There is currently little support for building reactive systems. Meta provides such support. Using Meta, a distributed system can be instrumented with a sensor and actuator abstraction that exposes the state of the system for purposes of control. Then, a control program can be written that interacts with the instrumented system using guarded commands. Of particular concern is the efficiency of control, so Meta allows the control program to be distributed in order to take advantage of locality as much as possible.
Model: client/server
Properties: UNIX-compatible, fault-tolerant, real-time support, atomic transactions,
RPC
Transparency:
Running on:
Date: 1991-?
Literature
Birman, Cooper and Marzullo: "ISIS and Meta Projects: Progress Report", Februar 1990.
Keth Marzullo and Mark Wood: "Making Real-Time Reactive Systems Reliable", Cornell University, Department of Computer, Ithaka New York, USA.
Keith Marzullo and Mark D.Wood: "Tools for Constructing Distributed Reactive Systems", Cornell Univerity, Department of Computer Science, Ithaca, New York 14853, February 22, 1991.
G.R. Sager
The Oryx/Pecos operating system is a message-based system which supports real-time, distributed applications. Its interprocess communications mechanisms provide a structuring tool simalar to monitors, capabilities and abstract data types.
Model: client/server, kernelized/micro kernel
Properties: synchronous message passing, modular, UNIX-compatible,
real-time support
Transparency:
Running on:
Date: 1985-?
Literature
G.R. Sager, et al.:" The Oryx/Pecos Operating System", AT&T Technical Journal, 64(1), pp. 251-268, 1985.
Jean-Michael Ayache, Jean-Pierre Courtiat,and Michael Diaz
Rebus is a research basis of the industrial real-time system MODUMAT 800. It is made up of functional units, i.e. programmable multiloop regulators and operate displays, linked together by a communication structure. The communication software, implemented on each interface board, provides a distributed excecutive based on a reliable link protocol and a robust bus allocation mechanism.
Model: multi-processor, bus-coupled, kernelized/micro kernel
Properties: fault-tolerant, real-time support
Transparency:
Running on:
Date: 1982-?
Literature
Jean-Michael Ayache, Jean-Pierre Courtiat, and Michael Diaz; "REBUS, A Fault-Tolerant Distributed System for Industrial Real-Time Control". IEEE Transactions on Computers, Vol. C-31, No. 7, July 1982.
J.M.Ayache, B. Carrichon, J.P. Courtiat, M. Diaz, B. Potin, and M. Shapiro: "Fault-tolerance in REBUS, A distributed system for industrial real-time control", Proc. Fault-Tolerant Computing Symposium, Portland, ME, June 1981.
Mike Malcolm and David R. Cheriton
Thoth is a real-time operating system which is designed to be portable over a large set of machines. It is currently running on two minicomputers with quite different architectures. Both the system and application programs which use it are written in a stack-oriented high-level language derived from B. Because the system is implemented by the same software on different hardware, it has the same interface to user programs. Hence, application programs which use Thoth are highly portable. Thoth encourages structuring programs as networks of communicating processes by providing efficient interprocess communication primitives. The Thoth operating system is built out of cooperating groups of lightweight processes. Thoth is a precursor of the V system.
Model: mini-computer
Properties: message passing, lightweigth processes real-time support, portable
Transparency: concurrency
Running on: Texas Instruments and Data General Nova
Date: 1979-?
Literature
Cheriton, D. R: "The Thoth System: Multi-process Structuring and Portability", American Elsevier, 1982.
D.R. Cheriton, M.A. Malcolm, L.S. Melen and G.R. Sager: "Thoth, a Portable Real-time Operating System", Communications of the ACM, Vol 22, No 2, 105-114, February 1979.
D.R. Cheriton: "Multi-process structuring, and the Thoth operating system", PhD. Thesis, University of Waterloo CS-79-19.
David Jefferson, Brian Beckman, Fred Wieland, Leo Blume, Mike DiLoreto, Phil Hontalas and Pierre Laroche
This system totally decouples real-time from system-time and uses a radical 'rollback' scheme to ensure correct ordering. It is intended for simulations on relatively tight coupled systems. The idea is basically to synchronize solely by rollback and message cancellation, never by blocking. Each node independently chooses which of its local objects to run next, basing its decision on which local object has the message with the earliest timestamp. Other nodes may simultaneously be choosing work with an earlier timestamp, work that may produce further messages to be sent to this node. Those messages could have earlier timestamps than the message this node just choose, in which case the work about to be done will eventually be rolled back, and all of its effects undone. It is an unusual way to do things, but, with suitable constraints, it works and works quite well.
Model: tightly coupled
Properties: real-time support, fault-tolerant
Transparency:
Running on: Caltech/JPL Mark III Hypercube
Date: 1984
Literature:
David Jefferson, Brian Beckman, Fred Wieland, Leo Blume, Mike DiLoreto, Phil Hontalas and Pierre Laroche: "Distributed Simulation and the Time Warp Operating System". Austin TX (USA) ACM Operating Systems Review, Vol. 20, No.4, pp. 77-93, November 1987.
Frederick Wieland, Lawrence Hawley and Abe Feinberg: "Implementing a Distributed Combat Simulation on the Time Warp Operating System". Pasadena, CA 1988 JPL, ACM, The 3rd Conference on Hypercube Concurrent Computers and Applications, Vol. II, Applications, January 1988, pp. 1269-1276.
J. Duane Northcutt
The Alpha kernel incorporates a number of carefully integrated, modern techniques, such as decentralized management of global system resources, kernel level support for atomic transactions and replication, object migration, judicious exploitation of hardware support, and strict exclusion of policy from the kernel mechanisms. To these, Alpha also adds the use of application-derived time constraints and relative importance attributes for managing resources to achieve optimal responsiveness and utility for its clients.
Model: loosely-coupled, homogeneous Workstations
Properties: atomic transactions, object-oriented, real-time support, lightweight
processes, process migration
Transparency: replication, migration, location, access
Running on: Sun-4
Date: 1986
Literature:
J. Duane Northcutt: "Mechanisms for reliable distributed real-time operating systems". Boston u.a. Acad. Pr. 1987, ISBN/ISSN 0-12-521690-4.
Hideyuki Tokuda and Clifford W. Mercer
ARTS is a distributed real-time operating system kernel, designed for real-time systems testbed. The goal of the ARTS Kernel is not to provide users with a predictable, analyzable, and reliable distributed real-time computing environment. It is based on a real-time object model which is incorporated with a time fence protocol and an integrated time-driven scheduling model. Since each scheduling policy is implemented as a kernel object, a user can easily add policies or changes the system's scheduling policy. ARTS is a precursor of RT-Mach.
Model: loosely coupled
Properties: object-oriented, real-time support
Transparency:
Running on: Sun-3 connected by Ethernet and Tolen-Ring
Date: 1987
Literature:
H. Tokuda and C.W. Mercer: "ARTS: A Distributed Real-Time Kernel". ACM Operating Systems Review, Vol. 23, No. 3, pp. 29-53, July 1989.
Michael L. Scott and Raphael A. Finkel
LYNX is a language for multi-computer systems programming. Processes in the language communicate by sending messages over communication channels, called links. Links may be created, manipulated, and distroyed dynamically to provide complete run time control over the interconnections among processes. Message type checking is performed at run time. Messages may be received explicitgy or may trigger the execution of entry procedures.
Model: multip-rocessor, client/server, kernelized/micro kernel
Properties: channels, shared-memory, run time control
Transparency: concurrency
Running on: Crystal multi-computer, Butterfly Parallel Processor
Date: 01.01.84 - ?
Literature
M.L. Scott: "An overview of Lynx", 1989 Univ. of Rochester Computer Science Dept., 27 pages $1.25, TR 308, Aug. 1989.
M.L. Scott and R.A. Finkel: "LYNX: A Dynamic Distributed Programing Language", 1984 IEEE, 0190-3918, 1984.
M.L. Scott: "Messages v. Remote Procedures is a False Dichotomy", ACM Sigplan Notices 18:5 (May 1983), pp. 934-941.
John A. Stankovic and Krithi Ramamritham
Springnet is a physical distributed system composed of a network of multi-processors each running the Spring kernel. Each multiprocessor contains application processors, system processors and I/O subsystem.
Springnet is based on the following considerations:
1. Tasks are part of a single application with a system-wide objective. The types of tasks that
occur in a real-time application are known beforehand and thus can be analyzed to
determine their characteristics. This information should be used at runtime.
2. The value imparted to the system by tasks should be maximized.
3. Predictability should be ensured so the timing properties of both individual tasks and the
system can be accessed.
4. Flexibility should be ensured so system modifications and on-line dynamics are more easiliy
accommodated.
Model: loosely-coupled, multi-processors, kernelized/micro kernel
Properties: real-time support
Transparency:
Running on:
Date: 1991-?
Literature
John A. Stankovic and Krithi Ramamritham: "The Spring Kernel: A new paradigm for real-time systems". IEEE Software, May 1991, pp. 63-73.
Insup Lee, Robert King, Victor Wolfe, Hanéne Ben Abdallah and R.P. Paul
TimexV2 is a real-time kernel that was developed to support distributed real-time applications. The kernel's salient features are a thread-based paradigm, consistent, user-definable scheduling, explicit dynamic timing constraints, real-time communication, and a two-tiered interrupt approach. To provide an uniform thread delay mechanism, an event is used to record the ocurrence of any activity on which a thread may wait. An event is triggered when a message arrives at a port, when a specified time arrives, when an exception occures, or when a device interrupts. To avoid the commonly found unpredictable behavior caused by interrupt handling, all device interrupts other than those from the clock cause events to be triggered and the interrupt handlers become threads to become threads to be scheduled as any other thread. TimexV2 uses the user datagram protocol (UDP) and the internet protocol to allow TimexV2 applications to communicate with other applications that are running on another processor.
Model: minicomputer, homogeneous, loosely-coupled, kernelized/micro kernel
Properties: real-time support, standard protocols, datagram, synchronization,
lightweight, preemptive multitasking, object-oriented, asynchronous
message passing
Transparency:
Running on: DEC MicroVAX
Date: 01.01.89 - ?
Literature:
I. Lee, R. King: "Timex: A distributed real-time kernel for multi-sensor robots". In Proc. of 1988 IEEE International Converence on Robotics and Automation, pp. 1587-1589, IEEE Council on Robotics and Automation, IEEE Computer Society Press, April 1988.
I. Lee, R.B. King, and R.P. Paul: "A predictable real-time kernel for distributed multiprocessor systems". Computer 22, No. 6, pp. 78-83, June 1989.
I. Lee, R. Kin and R.P. Paul: "RK: A Real-Time Kernel for a Distributed System with predictable Response". Tech. Report MS-CIS-88-78/GRASP LAB 155, Dept. of Computer and Information Science, Univ. of Pennsylvannia, Oct. 1988.
Ken Sakamura
TRON's ultimate objective is to support what is envisioned as "Highly Functionally Distributed Systems" or HFDS, that is, networks that span the globe, connecting large computers, personal workstations, and a multitude of "intelligent objects" such as appliances, environmental control systems, cameras, automobiles, etc., in which computers are embedded.
Model: loosely-coupled, object-oriented
Properties: WAN support
Transparency:
Running on: TRON CPU
Date: 1984 - 1990
Literature
Ken Sakamura: "TRON Project Special Issue", IEEE Micro, Vol. 7, No.2, April 1987.
Ken Sakamura: "New Concepts from the TRON Project", Tokyo 1987 Iwanami-Shoten, 1987.
Ken Sakamura: "TRON Project 1990", New York, Springer-Verlag, 1990, ISBN 0-387-70066-8.
This collection is not yet complete!!