Introduction

 Separate application from different supplier run on different

operating systems need some higher level of coupling
 Application often evolve by growing in size leading to
distribution in programs to different machines thus requiring
the need for a gradual on-line evolution
 Application grow in complexity thus requiring the need for
modularity of the application to be be mapped onto the
operating system concealing the unnecessary details of
distribution from the application
 Chorus Distributed System
There is a general nucleus running on each
Machine

Communication and distribution are managed at

the lowest level by this nucleus

CHORUS nucleus implements the real time required by real

time applications

Traditional operating systems like UNIX are built on top of

the Nucleus and use its basic services.
Nucleus Architecture
Chorus Nucleus
 Supervisor(machine dependent)

dispatches interrupts, traps and exception given by hardware
 Real-time executive

controls allocation of processes and provides synchronization
and scheduling
 Virtual Memory Manager

manipulates the virtual memory hardware and and local
memory resources. It uses IPC to request remote date in case of
page fault
 IPC manager

provides asynchronous message exchange and RPC in a location
independent fashion.
Version V3 onwards, the actors , RPC and ports
management were made a part of the Nucleus functions
Chorus Architecture
 The Subsystems provide
applications with with
traditional operating
system services
 The Nucleus is not a core
for a Specific Operating
system.
 Subsystem Interface -
e.g.. UNIX emulation
environment like
CHORUS/MiX
 Thus, functions of an
operating system are
split into groups of
services provided by
System Servers
(Subsystems)
 Chorus Architecture (cont.)
 System servers work together to form what is called the subsystem
 The Subsystem interface - implemented as a set of cooperating
server representing complex operating system abstractions
 Note: the Nucleus interface provides direct access to low-level
services of the CHORUS Nucleus
 Abstraction in the Chorus Nucleus-
UI(unique identifier)
Actor-collection of resources in a Chorus System. It defines a
protected address space. Three types of actors-user(in user
address space), system and supervisor
Thread
Message (byte string addressed to a port)
Port and Port Groups
Region
 Actors, port and port groups have UIs
A port is attached to one actor and allows the threads of that
Actor to
receive messages to that port
Actors - is trusted if the Nucleus allows to it perform sensitive
Nucleus
Operations
-is privileged if allowed to execute privileged instructions.
User actors-not trusted and not privileged
System actors-trusted but not privileged
Actors ,Threads and Port:
 A site can have multiple actors
 Actor is tied to one site and its threads are always executed
on that site
 Physical memory and data of the thread on that site only
 Actors nor thread can migrate to other sites.
 Threads communicate and synchronize by IPC mechanism
 However for threads in an actor share address space therefore
it can also use shared memory for communication
 An Actor can have multiple ports. Threads can receive
messages
on all the ports. However a port can migrate from one actor to
another
 Each Port has a logical and a unique identifier
Regions and Segments
 An actors address is divided into Regions
 A region of of an actor’s address space contains a portion of a
segment mapped to a given virtual address.
 Every reference to an address within the region behaves as a
reference to the mapped segment
 The unit of information exchanged between the virtual
memory system and the data providers is the segment
 Segments are global and are identified by capabilities(a unit of
data access control)
 A segment can be accessed by mapping (carried by Chorus
IPC) to a region or by explicitly calling a segment_read/write
system call
Messages and Ports
 A message is a contiguous byte string which is logically copied
from the
sender’s address space to the receiver’s address space
 Using coupling between large virtual memory management
and IPC large messages can be transferred using copy-on-
write techniques or by moving page descriptors
 Messages are addressed to Posts and not to actors. The port
abstraction provides the necessary decoupling of the interface
of a service and its implementation
 When a port is created the Nucleus returns both a local
identifier and a Unique Identifier (UI) to name the port
 Ports are grouped into Port Groups
 When a port group is created it is initially empty and port can
be added or deleted to it.
Port and Port Groups
 A port can be a part of more than one port groups
 Port groups also has a UIs
Segment representation within a
Nucleus
 Nucleus manages a per-segment local cache of physical pages
 Cache contains pages obtained from mappers which is used to
fulfill requests of the same segment data
 Algorithms are required for the consistency of the cache with
the original copies
 Deferred copy techniques is used whereby the Nucleus uses
the memory management facilities to avoid performing
unnecessary
copy operations
Chorus Subsystem
 A set of chorus actors that work together to export a unified
application programming interface are know as subsystems
 Subsystems like Chorus/MiX export a high-level operating
system abstractions such as process objects, process models
and data providing objects
 A portion of a subsystem is implemented as a system actor
executing in system space and a portion is implemented as
user actor
 Subsystem servers communicate by IPC
 A subsystem is protected by means of system trap interface
CHORUS/MiX: Unix Subsystem
 Objectives: implement UNIX services, compatibility with existing
application programs, extension to the UNIX abstraction to
distributed environment, permit application developers to
implement their own services such as window managers
 The file system is fully distributed and file access is location
independent
 UNIX process is implemented as an Actor
 Threads are created inside the process/actor using the u_thread
interface.
 Note: these threads are different from the ones provided by the
ucleus
 Signals to are either sent to a particular thread or to all the
threads in a process
Unix Server
 Each Unix Server is implemented as an Actor
 It is generally multithreaded with each request handled
by a thread
 Each server has one or more ports to which clients send
requests
 To facilitate porting of device drivers from a UNIX kernel
into the CHORUS server, a UNIX kernel emulation
emulation library library is developed which is linked
with the Unix device driver code.
 Several types of servers can be distinguished in a subsystem:
Process Manager(PM), File Manager (FM), Device Manager
(DM)
IPC Manager (IPCM)
Chorus/Mix: Unix with chorus
Process Manager (PM)
 It maps Unix process abstractions onto
CHORUS abstractions
 It implements entry points used by processes
to access UNIX services
 For fork, exec, kill etc the PM itself satisfies
the request
 For open, close, fork etc it invokes other
subsystem servers to handle the request
 PM accesses the Nucleus services through the
system calls
 For other services it uses other interfaces like
File manager, Socket Manager, Device
Manager etc
File Manager (FM)
 It provides disk level UNIX file system and acts
as mappers to the Chorus Nucleus
 FM implements services required by CHORUS
virtual memory management such as backing
store.
UNIX process
 A Unix process can be view as single thread of control mapped
into a single chorus actor whose Unix context switch is
managed by the Process Manager

 PM also attaches control port to each Unix process actor. A

control thread is dedicated to receive and proceed all
messages on this port
 For multithreading the UNIX system context switch is divide
into two subsystems: process context and u_thread context
Unix process as a Chorus Actor
Amoeba
 Objectives: to the user system should look like a single
computer
 The computing power is located in a processor pool containing
a number of CPU’s , each with its own local memory and its
own network connection.
 There are a couple of workstations through which users
access the system-for e.g. X-terminals
 Special servers and like file servers which need to run on
specialized hardware
 Amoeba software consists of a micro-kernel running on each
processor, and the collection of servers providing most of the
traditional operating system functionality.
Architecture
Micro-kernel
 Provides low-level memory management. Threads and allocate
or de-allocate segments of memory.
 Threads can be kernel threads or User threads which are a
part of a Process
 Micro-kernel provides communication between different
threads regardless of the nature or location of the threads
 RPC mechanism is carried out via client and server stubs. All
communication is RPC based in the Amoeba system
Amoeba servers
 Underlying concept: the services they provide: called object
 To create object client does an RPC with appropriate server
 To perform operation, the client calls the stub procedure
that builds a message containing the object’s capability and
then traps to kernel
 The kernel extracts the server port field from the capability
and looks it up in the cache to locate machine on which the
server resides
 If no cache entry is found-kernel locates server by
broadcasting
Bullet server
 File system is a collection of server process
 The file system is called a bullet server (fast: hence the name)
 Once file is created it cannot be changed, it can be deleted
and new one created in its place
 Sever maintains a table with one entry per file.
 When a client process wants to read a file it send the
capability for the file to server which in turn extracts the
object and finds the file using the object number
Directory Server
 Function: provide mapping from ASCII names to capabilities.
 Operation are provided to create and delete directories . The
directories are not immutable and therefore new entries can
be added to directory.
 Each file entry in the director has three protection domain
 User presents a directory server with a ASCII name , capability
and the server then checks the capability corresponding to the
name
 User can any one of the directory servers, if one is down it
can use others
Boot Server
 It provides fault tolerance to the system
 Check if the others severs are running or not
 A process interested in surviving crashes registers itself with
the server
 If a server fails to respond to the Boot server, it declares it as
dead and arranges for a new processor on which the new copy
of the process is started
 The boot server is itself replicated to guard against its own
failure
Applications
 Use as a Program development environment-it has a partial
UNIX emulation library. Most of the common library calls like
open, write, close, fork have been emulated.
 Use it for parallel programming-The large number of processor
pool make it possible to carry out processes in parallel
 Use it in embedded industrial application as shown in the
diagram below
Future
 Desirable properties of Future systems
 Seamless distribution-system determines where computation
excuet and data resides. User unaware
 Worldwide scalability
 Fault Tolerance
 Self Tuning-system takes decision regarding the resource
allocation, replication, optimizing performance and resource usage
 Self configurations-new machines should be assimilated
automatically
 Security
 Resource controls-users has some controls over resource location
etc
A Company would not want its financial documents to be stored in
a location outside its network system
Goals
 Aggressive abstraction-application programmer should not
have to worry about the mechanics of distributed
programming etc but concentrate on the user’s requirements
 Storage irrelevance
 Location irrelevance
 Just in time binding