Process Management in Distributed Operating Systems

As part of designing and building the Amoeba distributed operating system, we have come up with a simple set of mechanisms for process management that allows downloading process migration, checkpointing, remote debugging and emulation of alien operating system interfaces.\ud The basic process management facilities are realized by the Amoeba Kernel and can be augmented by user-space services: Debug Service, Load-Balancing Service, Unix-Emulation Service, Checkpoint Service, etc.\ud The Amoeba Kernel can produce a representation of the state of a process which can be given to another Kernel where it is accepted for continued execution. This state consists of the memory contents in the form of a collection of segments, and a Process Descriptor which contains the additional state, program counters, stack pointers, system call state, etc.\ud Careful separation of mechanism and policy has resulted in a compact set of Kernel operations for process creation and management. A collection of user-space services provides process management policies and a simple interface for application programs.\ud In this paper we shall describe the mechanisms as they are being implemented in the Amoeba Distributed System at the Centre for Mathematics and Computer Science in Amsterdam. We believe that the mechanisms described here can also apply to other distributed systems

Distributed debugging and tumult

A description is given of Tumult (Twente university multicomputer) and its operating system, along with considerations about parallel debugging, examples of parallel debuggers, and the proposed debugger for Tumult. Problems related to debugging distributed systems and solutions found in other distributed debuggers are discussed. The following are the main features of the debugger: it is event based, using a monitor for intercepting these events; record and reply are the main debugging techniques; preprocessing of events is done by programmable filters; the user interface is graphical, using grouping as the main abstraction mechanism. Parts of the debugger, as well as initial versions of the global and local event managers, have been implemented. A slow serial link between the front-end processor and the Tumult system has been replaced by a fast SCSI communication link. The user interface is partly textual, partly graphical. The languages used to implement the debugger are Modula-2 and C. The X Window System and OSF/Motif are used for the graphical user interfac

On debugging in a parallel system

In this paper a description is given of a partly implemented parallel debugger for the Twente University Multicomputer (TUMULT). The system's basic method for exchange of data is message passing. Experience has learned that most programming errors in application software are made in calls to the kernel and the interprocess communication. The debugger is intended to be used for locating bugs at this level in the application software. It is assumed that basic blocks of the debuggee can be debugged using a traditional sequential sourcelevel debugger

A Debugging Tool for Distributed Systems

This paper describes parts of the design of a debugger for a distributed real-time multimedia system. Emphasis lies on the distributed aspect of debugging, which means that attention is paid to the external behaviour of the processes. This type of debugging is useful to find communication or synchronization errors. However, experience shows that this is not enough: the debugger must also provide hooks for the user to use traditional sequential debuggers. This type of debugging focuses on the internal behaviour - or internal logic - of processes. For the sequential debugging part a normal debugger like GDB can be taken. Three key elements of the debugger are events, filters and recognizers. By definition events are the lowest level of system activity that may be observed by the event debugger. Filters are applied to remove events from the stream of events produced by the debuggee that are of no interest for the programmer. Recognizers are used to recognize behaviour -right or wrong- of the system. By combining events, different levels of abstraction are introduced, thus alleviating the task of the programme

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