9.

Chorus
History of Chorus
 Chorus started out at the French research institute INRIA in
1980, as a research project in distributed systems. It has
since gone through four versions, numbered from 0 through
3.
 The idea behind Version 0 was to model distributed
applications as a collection of actors.
 Version 1, which lasted from 1982 to 1984, focused on
multiprocessor research.
 Version 2 (1984-1986) was a major rewrite of the system,
in C.
 Version 3 was started in 1987. The version marked the
transition from a research system to a commercial product.
Goals of Chorus
1. High-performance UNIX emulation.
2. Use on distributed systems.
3. Real-time applications.
4. Integrating object-oriented programming
into Chorus.
 System Structure
UNIX subsystem Object-oriented subsystem

u1 u2 u3 User process
User
addr.
s1 s2 s3 System process
space

Kernel k1 k2 Kernel process

addr.
Management of
space
Microkernel names, processes,
threads, memory,
and communication.
Six key abstractions
Thread Address space

Region of address
Port: holding incoming
space
messages at any instant,
each port belongs to one
process.

Microkernel message Microkernel

network
 A capability in Chorus
UI of a port key to distinguish objects
Bits 13 3 48 64
Creation Type Epoch number Defined by the
site + counter subsystem

Can indicate site, port, or port group;

the other five combinations are reserved
for future use.
 An address space with four
mapped regions
Region stack Scratched segment

Unmapped address
Mapped portion of file F
Region file
Unmapped portion of file
Unmapped address F
Copy of program’s initial
Region data data
Read-only segment
Region program
 Kernel structure
Responsible for ports and messages

Interprocess communication
manager (portable) Manages paging
(low-level part of
Handles, processes, the paging system)
threads, and Real-time executive Virtual memory
scheduling (portable) (portable)

Machine-dependent
Supervisor (machine dependent) Portion of the
Caches traps, virtual
interrupts, and exceptions Memory manager
The UNIX Subsystem
 Since Chorus is now a commercial product, it must be
compatible with UNIX. Chorus accomplishes this goal by
providing a standard subsystem, called MiX, that is
compatible with System V.
 MiX is also compatible with UNIX in other ways. For
example, the file system is compatible, so Chorus can
read a UNIX disk. Furthermore, the Chorus device drivers
are interface compatible with the UNIX ones, so if UNIX
device drivers exist for a device machine, they can be
ported to Chorus with relatively littler work.
The Object-Oriented Subsytem
 It consists of three layers. The bottom layer
does object management in a generic way
and is effectively a microkernel for object-
oriented systems. The middle layer
provides a general runtime system. The top
layer is the language runtime system. This
subsystem, called COOL.
Process Management in Chorus
 A process in Chorus is a collection of
active and passive elements that work
together to perform some computation. The
active elements are the threads. The
passive elements are an address space
(containing some regions) and a collection
of ports (for sending and receiving
messages).
 Three kinds of processes
Type Trust Privilege Mode Space

User Untrusted Unpriviledged User User

System Trusted Unpriviledged User User

Kernel Trusted Privileged Kernel Kernel

 Privilege refers to the ability to execute I/O
and other protected instructions.
 Trust means that the process is allowed to
call the kernel directly.
Threads
 Every thread has its own private context (i.e., stack,
program counter, and registers).
 A thread is tied to the process in which it was created, and
cannot be moved to another process.
 Chorus threads are known to the kernel and scheduled by
the kernel, so creating and destroying them requires
making kernel calls.
 An advantage of having kernel threads is that when one
thread blocks waiting for some event (e.g., a message
arrival), the kernel can schedule other threads. Another
advantage is the ability to run different threads on
different CPUs when a multiprocessor is available.
 The disadvantage of kernel threads is the
extra overhead required to manage them.
 Threads communicate with one another by
sending and receiving messages.
 Chorus distinguishes the following states, but
they are not mutually exclusive:
1. ACTIVE – The thread is logically able to run.
2. SUSPENDED – The thread has been
intentionally suspended.
3. STOPPED – The thread’s process has been
suspended.
4. WAITING – The thread is waiting for some
event to happen.
Two synchronization
mechanisms
 Traditional semaphore, with operations UP
and DOWN.
 mutex, which is essentially a semaphore
whose values are restricted to 0 and 1.
Mutexes are used only for mutual
exclusion.
Scheduling
 CPU scheduling is done using priorities on a per-
thread basis.
 Each process has a priority and each thread has a
relative priority within its process. The absolute
priority of a thread is the sum of its process’
priority and its own relative priority.
 The kernel keeps track of the priority of each
thread in ACTIVE state and runs the one with the
highest absolute priority. On a multiprocessor with
k CPUs, the k highest-priority threads are run.
 High priority

A
These threads
are not
timesliced B

These threads D
C D C D C
are timesliced

Low priority
Traps, Exceptions, and Interrupts
 Traps are intentional calls to the kernel or a
subsystem to invoke services. Programs cause traps
by calling a system call library procedure. The
system supports two ways of handling traps.
1. all traps for a particular trap vector go to a single
kernel thread that has previously announced its
willingness to handle that vector.
2. each trap vector is tied to an array of kernel threads,
with the Chorus supervisor using the contents of a
certain register to index into the array to pick a
thread.
 Exceptions are unexpected events that are
caused by accident, such as the divide-by-
zero exception, floating-point overflow, or
a page fault.
 Interrupts are caused by asynchronous
events, such as clock ticks or the
completion of an I/O request.
 Kernel Calls for Process
Management
actorCreate Create a new process
ActorDelete Remove a process
ActorStop Stop a process, put its threads in
STOPPED state
actoreStart Restart a process from STOPPED state
actorPriority Get or set a process’ priority
actorExcept Get or set the port used for exception
handling
threadCreate Create a new thread
threadDelete Delete a thread
threadSuspend Suspend a thread

threadResume Restart a suspended thread

threadPriority Get or set a thread’s priority
threadLoad Get a thread’s context pointer
threadStore Set a thread’s context pointer
threadContext Get or set a thread’s execution context
mutexInit Initialize a mutex
mutexGet Try to acquire a mutex
mutexRel Release a mutex
semInit Initialize a semaphore
semP Do a DOWN on a semaphore
semV Do an UP on a semaphore
Memory Management in Chorus
 A region is a contiguous range of virtual
address, for example, from 1024 to 6143.
 A segment is a contiguous collection of
bytes named and protected by a capability.
 Mapping segments onto regions. It is not necessary
that a segment be exactly the size of its region.
 1. If the segment is larger than the region, only
a portion of the segment will be visible in the
address space, although which portion is visible
can be changed by remapping it.
 2. If the segment is smaller than the region, the
result of reading an unmapped address is up to the
mapper. For example, it can raise an exception,
return 0, or extend the segment.
Mappers
 Each mapper controls one or more
segments that are mapped onto regions. A
segment can be mapped into multiple
regions, even in different address spaces at
the same time.
Segments can be mapped into
multiple address space at the
same time
Process A Segments Process B

S1

S2
Distributed Shared Memory
 Chorus supports paged distributed shard memory in
the style of IVY. IT uses a dynamic decentralized
algorithm, meaning that different managers keep
track of different pages, and the manager for a page
change as the page moves around the system.
 The unit of sharing between multiple machines is the
segment. Segments are split up into fragments of one
or more pages. At any instant, each fragment is either
read-only, and potentially present on multiple
machines, or read/write, and present only on one
machine.
 Kernel Calls for Memory
Management
rgnAllocate Allocate a memory region and set its properties

rgnFree Release a previously allocated region

rgnInit Allocate a region and fill it from a given segment

rgnSetInherit Set the inheritance properties of a region

rgnSetPaging Set the paging properties of a region

rgnSetProtect Set the protection options of a region

rgnStat Get the statistics associated with a region

sgRead Read data from a segment

sgWrite Write data to a segment

sgStat Request information about a page

cache
sgFlush Request from a mapper to the
kernel asking for dirty pages
MpCreate Request to create a dummy
segment for swapping
MpRelease Request asking to release a
previously created segment
MpPullIn Request asking for one or more
pages
MpPushOut Request asking mapper to accept
one or more pages
 Communication in Chorus
 The basic communication paradigm in
Chorus is message passing.

64 bytes long Maximum of 64k bytes

header An optional fixed part Optional body

Identifies the source and destination

and contains protection identifiers and flags.
Port group 1 Port group 2

network
Communication Operations
 Two kinds of communication operations are
provided by Chorus: asynchronous send and
RPC.
 Asynchronous send allows a thread simply to
send a message to a port. There is no guarantee
that the message arrives and no notification if
something goes wrong.
 RPC uses blocking send and at-most-once
semantics.
 To all

1 2 3
 To any

1 2 3
 To 1

1 2 3
 Not to 1

1 2 3
 Kernel calls for communication
portCreate Create a port and return its capability

portDelete Destroy a port

portEnable Eanble a port so its messages count

on a receive from all ports
portDisable Disable a port

portMigrate Move a port to a different process

grpAllocate Create a port group

grpPortInsert Add a new port to an existing port

gro

grpPortRemove Delete a port from a port group

ipcSend Send a message asynchronously

ipcReceive Block until a message arrives

ipcGetData Get the current message’s body

ipcReply Send a reply to the current

message
ipcCall Perform a remote procedure call