EVENT BROKERS
An event is a case or a condition that requires the services of the microprocessor to handle it. Internal events are triggered by a running program and may result from software errors, such as a protection violation, or from execution exception, such as a page fault. External events are created by sources outside the execution of the current program and may include I/O events such as a disk request, timer-generated events, or even a message arrival in a message-passing multiprocessor system.
The response of a microprocessor to an event may be precise or imprecise, and may be concurrent or sequential. The response to an event is precise if proper handler execution ensures correct program behavior. This is guaranteed if the particular instruction causing the event (the faulting instruction) is identified, and any instructions that need the result of the faulting instruction are not issued until the handler has generated this result.
This definition of precise event handling enables us to use multitasking or multithreading to implement concurrent event handling; the event handler and the faulting program run concurrently in different task or thread contexts. This is in contrast to sequential event handling in which an event interrupts the faulting program, brings it to a sequentially consistent state, runs the handler to completion, and resumes the faulting program. Both concurrent and sequential event handling achieve the same end; all instructions get correct input operands, but do so through different means.
In this section, concurrent event handling with a multitasking or multithreading architecture will be highlighted, since it has several advantages over sequential event handling.
Event notification service
An event notification service (ENS) connects providers of information and interested clients. The ENS informs the clients about the occurrence of events from the providers.
Events can be, for instance, changes in existing objects or the creation of new objects such as a new measurement coming from a meter in a control system. The service learns about them by means of event messages, compiled either by the providers (push) or by the service actively observing the providers (pull). Clients define their interest in certain events by means of personal profiles. Profile creation is based on the profile definition language of the service. The information about observed events is filtered according to these profiles, and notifications are sent to the interested clients.
Figure 16.17 depicts the dataflow in the high-level architecture of an ENS. Keep in mind that the dataflow is independent of the delivery mode, such as push or pull. The tasks of an ENS can be subdivided into four steps. Firstly, the observable event (message) types are determined and advertised to the clients. This advertisement can be implicit, for example, provided by the client interface or due to information the client has about the service. Secondly, the clients’ profiles have to be defined through a client interface; they are stored within the service. Thirdly, the occurring events have to be observed and filtered by the ENS. Before creating notifications, the event information is combined to detect composite events. The messages can be buffered to enable more efficient notification (e.g., by merging several messages into one notification). Finally the clients have to be notified, immediately or according to a given schedule.
In object-oriented programming designs, the following considerations regarding the ENS can be very helpful.
(1) In programs, the event and its data can be written as abstract objects in the operating system code each can be an instance of the abstract event object. Event-data should be linked to an event. Each of these event objects includes its own trigger list, each node of which can be a client object to this event. Each client related to the same event should be registered into the trigger list of the corresponding event, either dynamically in run-time or initially when the system powers on. Data structures such as a hash-table can be chosen to maintain the event-client diagram in programs.
(2) The client object as nodes in the trigger list should include the handlers of the linked event, which can be routines, functions, or methods. When an event occurs while a program is running, the program context should go to the trigger list of this event immediately. Each node of this trigger list is drawn and the corresponding event handlers are run. This is called broadcast semantics.
(3) In multitask or multithread programming architecture, each of these routines can be implemented by one or more tasks or threads. Concurrent event handling requires synchronization between the handling routines. Although there are several ways of pursuing this synchronization, the context switch of tasks or threads in the kernel of a microprocessor chip seems essential for this purpose. We can also use software interrupts to deal with event handling routines; the occurrence of each event creates a software interrupt that leads the context to the handling routines. When the handling routines are complete, the context restores to the original process. However, for distributed control systems, message communications are the basic method of managing synchronization between the handling routines in different microprocessor chipsets.
Event triggers and broadcasts
Event triggers (or flags) are operations linked to types and associated with events. When the specified event occurs on an object of the linked type, the trigger operation will be invoked automatically. A trigger specifies its name along with the event that will trigger its execution. Four types of events may be specified: create, update, delete, and commit. A create event triggers execution after creation. Update and delete events trigger execution before any changes are made to the actual stored object. A commit event triggers execution before the commit is performed. All triggers and events refer only to that part of the object associated with the type in question. Thus, so addressing an object with an additional type will cause a new type part to be created and hence any create triggers associated with the acquired type to be invoked.
The event broadcast is responsible for sending a notification to all client applications that have previously registered into this event including the notification identifier of the notifying session server.
When broadcast semantics is used to signal the occurrence of the events, a useful programming technique is to put the broadcasts in a rule that is used to wake up applications that need to pay attention to something. In multitasking (or multithreading) operating systems, a reactive task (or reactive thread) mechanism is often used to wake up the applications that need to handle the event. The client will get back an event notification, just like all the other listening sessions. Depending on the application logic, this could result in useless work.
16.6.3 Event handling routines
An event handling routine is required to handle a given type of event. Here, the sources of the events are determined by reading event flags (or event triggers). These should then be reset and one event should be handled at a time. The handling of events continues in this fashion until all event flags are found to be inactive, and then the event routine is left.
It is recommended to use a trap mechanism to execute event handling routines, especially at the hardware level. This involves a set of event handling routines executed on behalf of user programs by the operating system, in which the trap instruction starts when a user program wishes the operating system to execute a specific routine, and then return control to itself. The event handling routine must have a mechanism for returning control from the operating system to the user program after completion. Similarly to interrupt handling mechanisms, this trap instruction causes the event service to execute the handling routine by changing the microprocessor to the starting address of the relevant routine on the basis of its trap vector. The interrupt vector is where the interrupt handlers are stored in an array of pointers. It also provides a way to get back to the program that initiated the trap instruction, referred to as a linkage.
After an event is handled, it resets the event flag first and then handles the particular event. If a new event from the same source arrives before the flag is reset and the previous event has been handled, this new event might be lost when the flag is reset. Thus, the chances of losing events are decreased when the flag is reset immediately.
However, if using a trap mechanism, event flags should be read again after handling the event, because the microprocessor trap may not exit from the event routine when there are pending events. While a previous event is being handled, a new event may have arrived (of the same type or a different type). By reading the event flags after each handled event, the user or programmer can easily implement an event priority scheme.