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

FIREBALL SOFTWARE DISTRIBUTION
FSD-2002A

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

• 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
 

• One of the main goals of the Amoeba development was to design a transparent distributed system that allows users to log into system as a whole: Transparency. That means: Hiding the comlexities of a distributed system from the users. Amoeba users should not be concerned about the number of processors in the system, nor must they know the location of the other machines or servers (like the Filesystem server...).

• Several machines connected over a network operate as a single system: Distribution. Amoeba gives its users the illusion of interacting with a single, powerfull system.

• Parallelism: On an Amoeba system, a single program or command can use multiple processors to increase performance. The user simply requests an operation, and the Amoeba OS decides the best way to execute the request. Amoeba will decide which processor (or processors) are appropriate for the request, based on the current state of the system. Additionaly, special development tools have been made for an Amoeba environment that take advantage of the inherent parallelism. For example, Amoeba supports a parallel 'make'  program.

• Peformance:  Much effort was given to meet this goal!!!This is accomplished with a newly developed High Performance network protocol called FLIP (Fast Local Internet Protocol). When FLIP was developed, none of the current protocols provided adequate support for distributed systems. FLIP performs clean, simple and efficient communication between distributed nodes.

• Development from the scratch; Amoeba doesen't based on any existing operating system

• Amoeba  interact with  the user as a UNIX-like Timesharing System

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: 
 

• 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 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 

• Low level I/O management

• Communication between processes or threads

• Low level Memory management

• Process and  thread (kernel/user space) management

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:

• 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

Memory management:

• 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.

I/O-Managment:

• 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)

Communication:

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 

• Data and
• Operations on this data

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: 

• Files
• Directories
• Memory segments
• Processes
• I/O-Devices (Harddrive...)
• Terminals
• ...

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: 

 

• 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:

• Mutexes
• Semaphores
• Signals

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:

• trans(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 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.