Presentation on theme: "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."— Presentation transcript:
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 u1u3u2 s1 k1 s2 k2 s3 Microkernel User process System process Kernel process UNIX subsystem Object-oriented subsystem User addr. space Kernel addr. space Management of names, processes, threads, memory, and communication.
Six key abstractions Microkernel network message Thread Port: holding incoming messages at any instant, each port belongs to one process. Region of address space Address space
A capability in Chorus Creation site TypeEpoch number + counter Defined by the subsystem Can indicate site, port, or port group; the other five combinations are reserved for future use. Bits 13 3 48 64 UI of a port key to distinguish objects
An address space with four mapped regions stack file data program Region Unmapped address Region Unmapped address Region Scratched segment Mapped portion of file F Unmapped portion of file F Copy of program’s initial data Read-only segment
Kernel structure Supervisor (machine dependent) Interprocess communication manager (portable) Real-time executive (portable) Virtual memory (portable) Responsible for ports and messages Handles, processes, threads, and scheduling Caches traps, interrupts, and exceptions Manages paging (low-level part of the paging system) Machine-dependent Portion of the virtual 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 UserUntrustedUnpriviledgedUser SystemTrustedUnpriviledgedUser KernelTrustedPrivilegedKernel Type Trust Privilege Mode Space
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 Low priority These threads are not timesliced These threads are timesliced A B CDC D DC
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 actorCreateCreate a new process ActorDeleteRemove a process ActorStopStop a process, put its threads in STOPPED state actoreStartRestart a process from STOPPED state actorPriorityGet or set a process’ priority actorExceptGet or set the port used for exception handling
threadCreateCreate a new thread threadDeleteDelete a thread threadSuspendSuspend a thread threadResumeRestart a suspended thread threadPriorityGet or set a thread’s priority threadLoadGet a thread’s context pointer threadStoreSet a thread’s context pointer threadContextGet or set a thread’s execution context
mutexInitInitialize a mutex mutexGetTry to acquire a mutex mutexRelRelease a mutex semInitInitialize a semaphore semPDo a DOWN on a semaphore semVDo 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 S1 S2 Process ASegmentsProcess 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 rgnAllocateAllocate a memory region and set its properties rgnFreeRelease a previously allocated region rgnInitAllocate a region and fill it from a given segment rgnSetInheritSet the inheritance properties of a region rgnSetPagingSet the paging properties of a region rgnSetProtectSet the protection options of a region rgnStatGet the statistics associated with a region
sgReadRead data from a segment sgWriteWrite data to a segment sgStatRequest information about a page cache sgFlushRequest from a mapper to the kernel asking for dirty pages
MpCreateRequest to create a dummy segment for swapping MpReleaseRequest asking to release a previously created segment MpPullInRequest asking for one or more pages MpPushOutRequest asking mapper to accept one or more pages
Communication in Chorus The basic communication paradigm in Chorus is message passing. headerAn optional fixed partOptional body Identifies the source and destination and contains protection identifiers and flags. 64 bytes long Maximum of 64k bytes
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.
Kernel calls for communication portCreateCreate a port and return its capability portDeleteDestroy a port portEnableEanble a port so its messages count on a receive from all ports portDisableDisable a port portMigrateMove a port to a different process
grpAllocateCreate a port group grpPortInsertAdd a new port to an existing port gro grpPortRemoveDelete a port from a port group
ipcSendSend a message asynchronously ipcReceiveBlock until a message arrives ipcGetDataGet the current message’s body ipcReplySend a reply to the current message ipcCallPerform a remote procedure call
Your consent to our cookies if you continue to use this website.