test

ChorusOS 5.0 Features and Architecture Overview

Synchronization

The ChorusOS operating system provides the following synchronization features:

Mutexes (MUTEX)

The ChorusOS operating system provides sleep locks in the form of mutual exclusion locks, or mutexes. When using mutexes, threads sleep instead of spinning when contention occurs.

Mutexes are data structures allocated in the client actors' address spaces. No microkernel data structure is allocated for these objects, they are simply designated by the addresses of the structures. The number of these types of objects that threads can use is thus unlimited. Blocked threads are queued and awakened in a simple FIFO order.

MUTEX API

The MUTEX API is summarized in the following table:

Function 

Description 

mutexGet()

Acquire a mutex 

mutexInit()

Initialize a mutex 

mutexRel()

Release a mutex 

mutexTry()

Try to acquire a mutex 

Real-Time Mutex (RTMUTEX)

The real-time mutex feature, RTMUTEX, provides mutual exclusion locks that support priority inheritance so that priority-inversion situations are avoided. It should be noted that, although the ChorusOS operating system exports this service to applications, it does not use this mechanism for synchronizing access to the objects it manages.

For details, see the RTMUTEX(5FEA) man page.

RTMUTEX API

The RTMUTEX API is summarized in the following table:

Function 

Description 

rtMutexGet()

Acquire a real time mutex 

rtMutexInit()

Initialize a real time mutex 

rtMutexRel()

Release a real time mutex 

rtMutexTry()

Try to acquire a real time mutex 

Semaphores (SEM)

The SEM feature provides semaphore synchronization objects. A semaphore is an integer counter and an associated thread wait queue. When initialized, the semaphore counter receives a user-defined positive or null value.

Two main atomic operations are available on semaphores: P (or ``wait'') and V (or ``signal").

Semaphores are data structures allocated in the client actors' address spaces. No microkernel data structure is allocated for these objects, they are simply designated by the address of the structures. The number of these types of objects that threads can use is therefore unlimited.

For details, see the SEM(5FEA) man page.

SEM API

The SEM API is summarized in the following table:

Function 

Description 

semInit()

Initialize a semaphore 

semP()

Wait on a semaphore 

semV()

Signal a semaphore 

Event Flags (EVENT)

The EVENT feature manages sets of event flags. An event flag set is a set of bits in memory associated with a thread-wait queue. Each bit is associated with one event. In this feature, the set is implemented as an unsigned integer, therefore the maximum number of flags in a set is 8*sizeof(int). Inside a set, each event flag is designated by an integer 0 and 8*sizeof(int).

When a flag is set, it is said to be posted, and the associated event is considered to have occurred. Otherwise, the associated event has not yet occurred. Both threads and interrupt handlers can use event flag sets for signaling purposes.

A thread can wait for a conjunctive (and) or disjunctive (or) subset of the events in one event flag set. Several threads can wait on the same event, in which case each of the threads will be made eligible to run when the event occurs.

Three functions are available on event flag sets: eventWait(), eventPost(), and eventClear().

Event flag sets are data structures allocated in the client actors' address spaces. No microkernel data structure is allocated for these objects. They are simply designated by the address of the structures. The number of these types of objects that threads can use is thus unlimited.

For details, see the EVENT(5FEA) man page.

EVENT API

The EVENT API is summarized in the following table:

Function 

Description 

eventClear()

Clear event(s) in an event flag set. 

eventInit()

Initialize an event flag set. 

eventPost()

Signal event(s) to an event flag set. 

eventWait()

Wait for events in an event flag set.