Events

 

In an operating system one of the requirements is to provide a mechanism for the various devices and components to communicate. The Nemesis kernel provides events and event channels to provide the underlying notification mechanism on which a range of communications channels can be constructed. There were a number of important considerations for the event mechanism in Nemesis.

• The mechanism must not force synchronous behaviour on domains which would find an asynchronous mechanism more convenient.
• It must be possible to communicate in a non-blocking manner (for example, for device drivers or servers which are QoS conscious).
• In loosely coupled multiprocessors, any explicit memory synchronisation required by the communication should only have to be performed when the mechansism is invoked. This requirement is to enable portable use of partially ordered memory systems such as an Alpha AXP multiprocessor, or the Desk Area Network.
• A thread scheduler within a domain can map communications activities to scheduling requirements efficiently; this necessitates that the communications primitives be designed in conjunction with the concurrency primitives.

These requirements dictate a solution which is asynchronous and non-blocking, and which can indicate that an arbitrary number of communications have occurred to the receiver.

The scheme is based on events the value of which can be conveyed from a sending domain via the kernel to a recipient domain via an event channel. An event is a monotonically increasing integer which may be read and modified atomically by the sending domain. This domain can request the current value be conveyed to the recipient domain by performing the kernel system call, send(). The recipient domain holds a readonly copy of the event which is updated by the kernel as a result of a send().

 
Figure 4:  Example of sending an event update

As an example, figure 4 shows the value of event number n in domain A being propagated (by the send system call) to domain B where it is event number m. The mapping table for event channels from A has the pair (B,m) for entry n so the kernel copies the value from A's event table to the appropriate entry in B's event table and places B's index (in this case m) into B's circular buffer fifo.

For each domain, the kernel has a protected table of the destinations of the event channels originating at that domain. A management domain called the Binder, described in section vi-A, is responsible for initialising these tables and thereby creating communication channels. Currently only ``point-to-point'' events are implemented, although there is nothing to prevent ``multicast'' events if needed in the future.

Exactly what an event represents is not known by the kernel, but only by the domains themselves. The relationship between these Nemesis events and event counts and sequencers [16] within the standard user thread library is discussed in section iv-D. Events are also used as the underlying notification mechanism supporting interrupt dispatch and inter-domain communication facilities at a higher level of abstraction - currently support is provided for inter-domain invocations (section vi), and streaming data operations (section vi-C).