Transcript 9. Chorus

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.
2.
3.
4.
High-performance UNIX emulation.
Use on distributed systems.
Real-time applications.
Integrating object-oriented programming
into Chorus.
System Structure
UNIX subsystem
Object-oriented subsystem
u1
User
addr.
space
Kernel
addr.
space
s1
s2
k1
Microkernel
u2
u3
User process
s3
System process
k2
Kernel process
Management of
names, processes,
threads, memory,
and communication.
Six key abstractions
Address space
Thread
Port: holding incoming
messages at any instant,
each port belongs to one
process.
Microkernel
message
Region of address
space
Microkernel
network
A capability in Chorus
UI of a port
Bits
13
Creation
site
3
key to distinguish objects
48
Type Epoch number
+ counter
64
Defined by the
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
Region
file
Unmapped address
Region
data
Region
program
Mapped portion of file F
Unmapped portion of file
F
Copy of program’s initial
data
Read-only segment
Kernel structure
Responsible for ports and messages
Interprocess communication
manager (portable)
Handles, processes,
threads, and
Real-time executive
scheduling
(portable)
Virtual memory
(portable)
Supervisor (machine dependent)
Caches traps,
interrupts, and exceptions
Manages paging
(low-level part of
the paging system)
Machine-dependent
Portion of the virtua
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 objectoriented 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
User
Trust
Privilege
Untrusted Unpriviledged
Mode
Space
User
User
User
System Trusted
Unpriviledged
User
Kernel
Privileged
Kernel Kernel
Trusted


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 perthread 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
These threads
are timesliced
Low priority
B
C
D
C
D
D
C
Traps, Exceptions, and Interrupts

1.
2.
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.
all traps for a particular trap vector go to a single
kernel thread that has previously announced its
willingness to handle that vector.
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-byzero 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
Restart a process from STOPPED state
actoreStart
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
S1
S2
Process B
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
header
An optional fixed part
Identifies the source and destination
and contains protection identifiers and flags.
Maximum of 64k bytes
Optional body
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
portDisable
Eanble a port so its messages count
on a receive from all ports
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
Perform a remote procedure call
ipcCall