START FSD-Amoeba ARTICLES
DISTRIBUTION BOOKS
AMOEBA LINKS
HARDWARE EVENTS
DOWNLOAD ORCA
INSTALL YOUR HELP
DOCUMENTS HOME
PREV NEXT

SourceForge.net Logo

FIREBALL SOFTWARE DISTRIBUTION
FSD-2002A

Amoeba: A Distributed Operating System

Content

  1. History
  2. System development
  3. System architecture
  4. The Amoeba Microkernel
  5. Amoeba's Object concept
  6. Process management
  7. Memory management
  8. Communication

1.History

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: 
  1. Workstations
  2. Pool Processors
  3. Specialized Servers (File server...)
  4. Gateways

In more detail: 
 

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 Micro-kernel
 

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. 

Process concept:

Memory management:

I/O-Managment:

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. 

6. Process management
 

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: 


 

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.

7. Memory management
 

Amoeba supplies a simple memory management based on segments. Each process owns at least three segments:

  1. Text/Code segment
  2. Stack segement for the main thread/process
  3. Data segment

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.

8. Communication
 

All processes, the kernel too, communicate with a standardized RPC (Remote procedure call) interface. There are only three functions to reach this goal:

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 reply function.

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.