|Amoeba: A Distributed Operating System|
- Developed at the Vrije Universiteit Amsterdam, Netherland. Chief designer: Andrew S. Tanenbaum; other developpers were Frans Kaashock, Sape J. Mullender, Robbert van Renesse, Leendert van Doorn, Kees Verstoep and many, many more.
- First proto release in 1983 (V1.0), last official release 1996 (V5.3)
- Supports multiple architectures: 68k, i80386, SPARC
2. Design goals
3. System architecture
Amoeba implements a universell distributed Client-Server-Modell. In fact, basically the whole system needs only three Functions to do all the work: The transaction call from the Client, and the GetRequest and PutReply functions on the Server side.
An Amoeba System consists of four principle components:
- Pool Processors
- Specialized Servers (File server...)
In more detail:
- Amoeba is designed as a collection of micro kernels. Thus the Amoeba system consists of many CPU's connected over a network. Each CPU owns his own local Memory in the range from 2MB to several 100MB. A huge number of Processor's build the so called Processorpool. This group of CPUs can be dynamically allocated as needed by the system and the users. Specialized servers, called Run server, distribute processes in a fair manner to these machines.
- Many different Processor architectures are supported: i80386(Pentium), 68k, SPARC. Today, only the i80386 architecute is significant for building an Amoeba system (cheap!!!).
- Workstations allow the users to gain access to the Amoeba system. There is typically one workstation per user, and the workstation are mostly diskless; only a workstation kernel must be booted (from floppy, via tftp, burned in Flash-EEPROM). Amoeba supports X-Windows and UNIX-emulation.
- At heart of the Amoeba system are several specialized servers that carry out and synchronize the fundamental operations of the kernel. Amoeba has a directory server (called SOAP) that is the naming service for all objects used in the system. SOAP provides a way to assign ASCII names to an object so it's easier to manipulate(by humans). The directory server can replicate files without fearing their change. Amoeba has of course a file server (called the Bullet Server) that implements a stable high speed file service. High speed is achieved by using a large buffer cache. Since the files are first created in cache, and are only written to disk when they are closed, all the files can be stored contigously. The underlying idea behind immutable files is to prevent the replication mechanism from undergoing race conditions. And file server crashes normally don't result in an inconsistent file system! The Bullet server uses the virtual disk server to perform I/O to disk, so it's possible that the file server run as a normal user program! The Boot server controll all global system servers (outside the kernel): start, check and poll, restart if crashed.
- All Amoeba objects (files, programs, memory segments, servers) are protected and discribed with so called Capabilities (see below).
An example for a processor pool: About 60 -80 Sun motherboards
were build into a rack system at the Vrije Univerity. Of course cheap and
normal IBM-PC 's can be used as CPU-Servers, too!
4. The Amoeba
A small piece of code, called the microkernel, is present on all Amoeba machines and they run nearly the same microkernel which handles
Server processes (see above) supply other operating system services and generally run in user mode. This job specialization allows the microkernel to be small and efficient, increases reliability, allows as much as possible of the operating system to run as user processes, providing flexibility and no extra burdens are added to individual CPUs with faciliites that it doesn't need.
- Low level I/O management
- Communication between processes or threads
- Low level Memory management
- Process and thread (kernel/user space) management
- Amoeba supports traditional process concept
- Processes consists of several threads (at least one)
- Each thread has his own registers, Instruction Pointer, stack; but all threads of a process share the same memory region
- Example: File server. Each request is handled by one thread, but all threads use the same cache; synchronization through Mutex and Semaphores
- Threads can allocate and deallocate blocks of memory, called Segments .
- These segments can be read and written, and can be mapped into and out of the address space of the process.
- A process owns at leat one segment, but may have many more of them.
- Segments can be used for text, data, stack, or any other purpose the process desires. The operating system doesen't enforce any particular pattern on segment usage.
- For each I/O-Device attached to a machine, there is a device driver in the kernel. The driver manages all I/O for the device.
- All drivers are static linked to the kernel; no dynamic Module support
- Mostly the communication with Device-Drivers are performed through the standard message protocoll (like the rest of the system in user space)
Two forms of communication are provided:
- Point-to-Point communication
- Group communication
5. Amoeba's Object concept
The central point of the software concept for a server implementation is the Objectconcept. Each object consists of
Amoeba is organized as a collection of objects (essentially abstarct data types), each with some number of operations that processes can perform on it. Operations on an object are performed by sending a message to the object's server.Objects are created by processes and managed by the corresponding server. There are many different object classes:
Operations on objects are performed with Stub-procedures.When an object is created, the server returns a Capability. The capability is used to address and protect the object. A typically capability is shown below.
The Port field identifies the server. The Object field tells which object is beeing referred to, since a server normally will manage several objects. The Rights field specifies which operations are allowed (e.g. capability for a file may be read only). Since capabilities are managed in user space, the Check field is needed to protect them cryptographically, to prevent users from tampering with them.
A process is an object in Amoeba. Information about the processes in Amoeba are contained in capabilities and in a data structure called a process descriptor, which is used for process creation and stunned processes (and process migration). The process descriptor consists of four components:
- The host descriptor provides the requierements for the system where the process must run, by describing what machine it can be run
- The capabilities include the capability of the process which every client needs, and the capability of a handler, which deals signals and process exit
- The segment component describes the layout of the addess space (see below)
- The thread component describes the state of each of the threads (see below) in the process and their state informations(IP, Stack,...)
Amoeba supports a simple thread model. When a process starts up, it has at least one thread. The number of threads is dynamic. During execution, the process can create additional threads. And existing threads can terminate. All threads are managed by the kernel. The advantage of this design is that when a thread does a RPC, the kernel can block that thread and schedule another one in the same process if one is ready!
Three methods are provided for thread synchronization:
A Mutex is like a binary semaphore. It can be in one of two states, locked or unlocked. Trying to lock an unlocked mutex causes it to become locked. The calling thread continues. Trying to lock a mutex that is already locked causes the calling thread to block until another thread unlocks the mutex.The second way threads can synchronize is by counting Semaphores. These are slower than mutexes, but there are times when they are needed. A semaphore can't be negative. Try down a zero semaphore causes the calling thread to block until another thread do a up operation on the semaphore.
Signals are asynchronous interrupts sent from one thread to another in the same process. Signals can be raised, caught, or ignored. Asynchronous interrupts between processes use the stun mechanism.
Amoeba supplies a simple memory management based on segments. Each process owns at least three segments:
Each further thread gets his own stack segment, and the process can allocated arbitrary additional data segments.
All segments are page protected by the underlying MMU, the kernel segments, too.
All processes, the kernel too, communicate with a standardized RPC (Remote procedure call) interface. There are only three functions to reach this goal:
req_header, req_buf, req_size, rep_header,rep_buf, rep_size)
-> do a transaction to another server
getreq( req_header, req_buf, req_size)
-> get a client request
putrep( rep_header, rep_buf, rep_size)
-> send a reply to the client
The first function is used by client to send a
message to a server, and get a reply from the server on this request. The
reply and request buffers are generic memory buffers (char). The reply and
request headers are simple data structures to describe the request and the
capability of the server. On the other side, teh server calls within an
infinite loop the getreq function. Each time a client sends this server
(determined by a server port - see capabilities for details) a message, the
getreq function returns with the client data
filled in the request buffer, if any. The request header contains
informations about the client request.
Because the client expects a reply, the server
must send a reply (either with or without reply data) using the
Based on the article: Amoeba: An Overview of a
Distributed Operating System by Eric W. Lund - March 29, 1998, Rochester
Institute of Technolog and informations about Amoeba taken from a web site
from the University of Halle. Additional parts are taken from the Amoeba
tribute site from Stephen Wagner. Furthermore the classics: The Amoeba
kernel, Andrew S. Tanenbaum, M.F. Kaashoek.