PERQ

Abstract: This paper describes experiences gained during the design, implementation and use of the CMU Accent Network Operating System, its. predecessor, the University of Rochester RIG system and its successor CMU’s Mach multiprocessor operating system. It outlines the major design decisions on which the Accent kernel was based, how those decisions evolved from the RIG experiences and how?hey had to be modified to properly handle general purpose multiprocessors in Mach. Also discussed are some of the major issues in the implementation of message-based systems, the usage patterns observed with Accent over a three year period of extensive use at CMU and a timing analysis of various Accent functions. 1. Background Mach is a multiprocessor operating system kernel currently under development at Carnegie-Mellon University. In addition to binary compatibility with Berkeley’s current UNIX 4.3 bsd release, Mach provides a number of new facilities not available in 4.3, including: l Support for tightly coupled and loosely coupled general purpose multiprocessors. . An internal symbolic kernel debugger. l Support for transparent remote file -access between autonomous systems. l Support for large, sparse virtual address spaces, copy-on-write virtual copy operations, and rpemory mapped files. l Provisions for user-provided memory objects and pagers. l Multiple threads of control within a single address space. l A capability-based interprocess communication facility-integrated with virtual memory management to allowrtransfer of large amounts of data (up to the size of a process address space) via copy-on-write techniques. l Transparent network interprocess communication with preservation of capability protection across network boundaries. As of May 1986, Mach runs on most uniprocessor VAX architecture machines: VAX 11/750, 111780, 111785, 8200, 8600, 8650, MicroVAX I, and MicroVAX II. Mach also runs on two multiprocessor VAX machines, the four (1 l/780 or 111785) processor VAX 1 l/784 with 8 MB of shared memory the VAX 8300 (with up to 4 processors). Mach has already been ported to the IBM RT/PC and work has begun on ports to the uniprocessor SUN 3 and multiprocessor Encore MultiMax. The current version of the system, Mach-l, includes all of the features listed above and is in production use by CMU researchers on a number of projects including a multiprocessor speech recognition system called Agora [5] and a project to build parallel production systems. Mach is the logical successor to CMU’s Accent [16,17] kernel .. an operating system designed to support a large network of uniprocessor scientific personal computers. The design and implementation of Accent was in turn based on experiences gained during the development of the University of Rochester’s RIG system [3,14], a message-based network access machine. Both RIG and Accent have seen considerable use over the years. RIG provided a variety of functions including terminal support and remote file access within the Rochester environment until early this year when the last RIG machine was decommissioned. Accent continues in use at CMU as the basic operating system for a network of 150 PERQ workstations and has seen commercial use in printing and publishing workstations as well as engineering design systems. As a third generation network operating system Mach, benefits from the lessons learned in over ten years of design, implementation and use of RIG and Accent. This paper summarizes the lessons of those systems and their impact on the design and implementation of Mach. 2. The Evolution of Accent from RIG Implementation of RIG began in 1975 on an early version of the Data General Eclipse mini-computer. The first usable version of the system came on-line in the fall of 1976. Eventually the Rochester network included several RIG Eclipse nodes as network servers and a number of Xerox Altos acting as RIG client hosts. RIG provided clients network file services, ARPANET access, printing services and a variety of other functions. Active development continued well into the 1980’s but obsolescence of its Data General Eclipse and Xerox Alto hardware base eventually dictated its demise in the Spring of 1986.

Abstract: Facilities that support distributed transactions on user-defined types can be implemented efficiently and can simplify the construction of reliable distributed programs. To demonstrate these points, this paper describes a prototype transaction facility, called TABS, that supports objects, transparent communication, synchronization, recovery, and transaction management. Various objects that use the facilities of TABS are exemplified and the performance of the system is discussed in detail. The paper concludes that the prototype provides useful facilities, and that it would be feasible to build a high performance implementation based on its ideas. This work was supported by IBM and the Defense Advanced Research Projects Agency, ARPA Order No. 3597, monitored by the Air Force Avionics Laboratory under Contract F33615-81-K-1539, and by graduate fellowships from the National Science Foundation and the Office of Naval Research. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of any of the sponsoring agencies or the US government. Accent is a trademark of Carnegie.Mellon University. Perq is a trademark of Perq Systems Corporation. TAB is a trademark of the Coca-Cola Company. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. © 1985 A C M 0 8 9 7 9 l1 7 4 1 1 2 / 8 5 0 1 2 7 $ 0 0 . 7 5 1. In t roduct ion General purpose facilities that support distributed transactions are feasible to implement and useful in simplifying the construction of reliable distributed applications. To justify this assertion, this paper describes the design, implementation, use, and performance of TABS [Spector et al. 85], a prototype facility that supports transactions on user-defined abstract objects. We attempt to generalize from our experi6nces with the prototype, particularly in the sections on the usage and performance of TABS. We define a distributed transaction facility as a distributed collection of components that supports not only such standard abstractions as processes and inter-process communication, but also the execution of transactions and the implementation of objects on which operations can be performed. Although there is room for diversity in its exact functions, a distributed transaction facility must make it easy to initiate and commit transactions, to call operations on .objects from within transactions, and to implement abstract types that have correct synchronization and recovery properties. Transactions provide three properties that should make them useful in a variety of distributed applications [Lomet 77, Liskov 82, Spector and Schwarz 83]. Synchronization properties, such as serializability, guarantee that concurrent readers and writers of data do not interfere with each other. Failure atomicity simplifies the maintenance of invariants on data by ensuring that updates are not partially done. Permanence provides programmers the luxury of knowing that only catastrophic failures will corrupt or erase previously made updates. Certainly, these properties of transactions are useful in database applications [Gray 78, Date 83]. Database applications are typically characterized by the need for absolute data integrity, permanent updates, and careful synchronization between processes that access large quantities of shared data. When considering the application of transactions to other domains such as the construction of distributed operating systems and real time systems, there are questions pertaining to what transaction facilities should be provided, how they should

Abstract: This paper introduces a modified version of path expressions called Path Rules which can be used as a debugging mechanism to monitor the dynamic behavior of a computation. Path rules have been implemented in a remote symbolic debugger running on the Three Rivers Computer Corporation PERQ computer under the Accent operating system.

Abstract: This dissertation investigates automatic partitioning, scheduling, and fault tolerance for distributed applications on a network of personal computers. Previous distribution systems in loosely coupled environments have used a special process control language or special language features to describe the task structure of a program while the lower level algorithms were defined in a standard algorithmic language. Like many of the systems proposed for tightly coupled processors, we use a single applicative language for both the task structure and the algorithm, doing away with the distinction between tasks and functions by making every function a potential task. However, the network environment has deeply influenced the design: the long communication latencies commit the system to large grain parallelism and carefully planned communication strategies. The product of the research is a language and execution environment called STARDUST. STARDUST programs are written in a general-purpose applicative language and marked with an estimate of each function's execution time. The system partitions the programs by expanding user function calls with high execution time estimates and by breaking up calls to the system's list operators. The segments are scheduled on the available processors, taking into account both load balancing and the costs of message passing. Failed tasks can be restarted by moving them to surviving processors. Three sets of experiments run on Perq computers and an Ethernet gave two successes and one failure. The quick sort experiment failed to achieve significant speedups due to some poor scheduling heuristics and large amounts of overhead that could not be transferred to other processors. The six-processor versions of the signal processing and molecular modelling experiments showed speedups of about two when the exported function calls took one second to evaluate, and speedups of over three when the exported calls took five seconds. Message passing and interpreter overhead are the main reasons that such a large granularity is needed; partitioning and scheduling do not contribute significantly to overall execution time. The experimental results also include a demonstration of automatic failure recovery and run-time redundant subcomputation elimination.