9. Chorus

1
9. Chorus
2
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.

3
Goals of Chorus

• High-performance UNIX emulation.
• Use on distributed systems.
• Real-time applications.
• Integrating object-oriented programming into
  Chorus.

4
System Structure
Object-oriented subsystem
UNIX subsystem
User process
u1
u3
u2
User addr. space
System process
s1
s2
s3
Kernel process
k2
Kernel addr. space
k1
Management of names, processes, threads,
memory, and communication.
Microkernel
5
Six key abstractions
Address space
Thread
Region of address space
Port holding incoming messages at any
instant, each port belongs to one process.
Microkernel
Microkernel
message
network
6
A capability in Chorus
UI of a port key to
distinguish objects
Bits 13 3 48
64
Creation site
Type
Epoch number counter
Defined by the subsystem
Can indicate site, port, or port group the other
five combinations are reserved for future use.
7
An address space with four mapped regions
stack
Region Unmapped address Region Unmapped
address Region Region
Scratched segment Mapped portion of file
F Unmapped portion of file F Copy of programs
initial data Read-only segment
file
data
program
8
Kernel structure
Responsible for ports and messages
Interprocess communication manager (portable)
Manages paging (low-level part of the paging
system)
Handles, processes, threads, and scheduling
Real-time executive (portable)
Virtual memory (portable)
Machine-dependent Portion of the virtual Memory
manager
Supervisor (machine dependent)
Caches traps, interrupts, and exceptions
9
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.

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

11
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).

12
Three kinds of processes
Type Trust
Privilege Mode
Space
User Untrusted Unpriviledged User User
System Trusted Unpriviledged User User
Kernel Trusted Privileged Kernel Kernel
13

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

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

15

• The disadvantage of kernel threads is the extra
  overhead required to manage them.
• Threads communicate with one another by sending
  and receiving messages.

16

• Chorus distinguishes the following states, but
  they are not mutually exclusive
• ACTIVE The thread is logically able to run.
• SUSPENDED The thread has been intentionally
  suspended.
• STOPPED The threads process has been
  suspended.
• 4. WAITING The thread is waiting for some
  event to happen.

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

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

19
High priority
A
These threads are not timesliced
B
These threads are timesliced
D
C
D
C
D
C
Low priority
20
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.
• 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.

21

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

22
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
23
threadCreate Create a new thread
threadDelete Delete a thread
threadSuspend Suspend a thread
threadResume Restart a suspended thread
threadPriority Get or set a threads priority
threadLoad Get a threads context pointer
threadStore Set a threads context pointer
threadContext Get or set a threads execution context
24
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
25
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.

26

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

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

28
Segments can be mapped into multiple address
space at the same time
Process A
Segments
Process B
S1
S2
29
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.

30
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
31
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
32
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
33
Communication in Chorus

• The basic communication paradigm in Chorus is
  message passing.

Maximum of 64k bytes
64 bytes long
header
An optional fixed part
Optional body
Identifies the source and destination and
contains protection identifiers and flags.
34
Port group 1
Port group 2
network
35
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.

36
To all
2
3
1
37
To any
2
3
1
38
To 1
2
3
1
39
Not to 1
2
3
1
40
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
41
grpAllocate Create a port group
grpPortInsert Add a new port to an existing port gro
grpPortRemove Delete a port from a port group
42
ipcSend Send a message asynchronously
ipcReceive Block until a message arrives
ipcGetData Get the current messages body
ipcReply Send a reply to the current message
ipcCall Perform a remote procedure call