Amoeba - A distributed Operating System for the 1990s

n the nexi decdde, computer prices will drop 50 low that IO, 20, or per-1 haps IO0 powerful microprocessors per user will be feasible. All this computing power will have to be organized in a simple, efficient, and fault-tolerant system that is easy to use. The basic problem with current networks of PCs and workstations is that they are not transparent; that is, users are aware of the other machines. The user logs into one machine and uses that machine only, until doing a remote login to another machine. Few if any programs take advantage of multiple CPUs, even when all are idle

The Amoeba Distributed Operating System - A Status Report

As the price of CPU chips continues to fall rapidly, it will soon be economically feasible to build computer systems containing a large number of processors. The question of how this computing power should be organized, and what kind of operating system is appropriate then arises. Our research during the past decade has focused on these issues and led to the design of a distributed operating system, called Amoeba, that is intended for systems with large numbers of computers. In this paper we describe Amoeba, its philosophy, its design, its applications, and some experience with it. 1

AIL - a class-oriented RPC stub generator for Amoeba

AIL – an acronym for Amoeba Interface Language – is a class-oriented RPC stub generator, used with Amoeba’s RPC primitives. Together with Amoeba’s facilities for manipulating capabilities (bit patterns that are unforgeable references to objects maintained by servers anywhere on a network), AIL provides a completely object-oriented view of a distributed operating system. Input to AlL consists of class and type definitions and generator directives; output are several flies containing function definitions to be compiled and linked with clients and servers. Class definitions consist mainly of function headers (specifying parameter types, etc.). Classes can inherit multiple other classes. AlL can (in principle) generate stubs for different programming languages, so clients and servers need not be written in the same language

Beyond UNIX - A True Distributed System for the 1990s

UNIX has been around now for almost 20 years. At the time UNIX began, most departments felt themselves well-endowed indeed if they owned a single PDP-11/45 with 256K memory and a 2.5M RK05 disk. Nowadays a laptop would be embarrassed to have only that. It is our hypothesis that UNIX is no longer the appropriate kind of operating system for the 1990s. In this paper, a new system, Amoeba, will be described, that we believe meets the requirements for distributed computing in the 1990s

Evaluation of hardware architectures for parallel execution of complex database operations

Abstract New database applications, primarily in the areas of engineering and knowledge-based systems, refer to complex objects (e.g. representation of a CAD workpiece or a VLSI chip) while performing their tasks. Retrieval, maintenance, and integrity checking of such complex objects consume substantial computing resources which were traditionally used by conventional database management systems in a sequential manner. Rigid performance goals dictated by interactive use and design environments imply new approaches to master the functionality of complex objects under satisfactory time restrictions. Because of the object granularity, the set orientation of the database interface, and the complicated algorithms for object handling, the exploitation of parallelism within such operations seems to be promising. Our main goal is the investigation and evaluation of different hardware architectures and their suitability to efficiently cope with workloads generated by database operations on complex objects. Apparently, employing just a number of processors is not a panacea for our database problem. The sheer horse power of machines does not help very much when data synchronization and event serialization requirements play a major role during object handling. What are the critical hardware architecture properties? How can the existing MIPS be best utilized for the data management functions when processing complex objects? To answer these questions and related issues, we discuss different kinds of architectures combining multiple processors: loosely-, tightly-, and closely-coupled. Furthermore, we consider parallelism at different levels of abstraction: the distribution of (sub-)queries or the decomposition of such queries and their concurrent evaluation at an inter-or intra-object level. Finally, we give some thoughts as to the problems of load control and transaction management