Events

From Rosetta Code
Revision as of 17:18, 10 June 2009 by rosettacode>Dmitry-kazakov (New task + Ada solution)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Task
Events
You are encouraged to solve this task according to the task description, using any language you may know.

Event is a synchronization object. An event has two states signaled and reset. A task may await for the event to enter the desired state, usually the signaled state. It is released once the state is entered. Releasing waiting tasks is called event notification. Programmatically controlled events can be set by a task into one of its states.

In concurrent programming event also refers to a notification that some state has been reached through an asynchronous activity. The source of the event can be:

  • internal, from another task, programmatically;
  • external, from the hardware, such as user input, timer, etc. Signaling an event from the hardware is accomplished by means hardware of interrupts.

Event is a low-level synchronization mechanism. It neither identify the state that caused it signaled, nor the source of, nor who is the subject of notification. Events augmented by data and/or publisher-subscriber schemes are often referred as messages, signals etc.

In the context of general programming event-driven architecture refers to a design that deploy events in order to synchronize tasks with the asynchronous activities they must be aware of. The opposite approach is polling sometimes called busy waiting, when the synchronization is achieved by an explicit periodic querying the state of the activity. As the name suggests busy waiting consumes system resources even when the external activity does not change its state.

Event-driven architectures are widely used in GUI design and SCADA systems. They are flexible and have relatively short response times. At the same time event-driven architectures suffer to the problems related to their unpredictability. They face race condition, deadlocking, live locks and priority inversion. For this reason real time systems tend to polling schemes, trading performance for predictability in the worst case scenario.

Variants of events

Manual-reset event

This event changes its state by an explicit request of a task. I.e. once signaled it remains in this state until it will be explicitly reset.

Pulse event

A pulse event when signaled releases all tasks awaiting it and then is automatically reset.

Sample implementations / APIs

Show how a manual-reset event can implemented in the language or else use an API to a library that provides events. Write a program that waits 1s and then signals the event to a task waiting for the event.

Ada

Ada provides higher-level concurrency primitives, which are complete in the sense that they also allow implementations of the lower-level ones, like event. Here is an implementation of the manual-reset event.

The event interface: <lang ada> protected type Event is

  procedure Signal;
  procedure Reset;
  entry Wait;

private

  Fired : Boolean := False;

end Event; </lang> The event implementation> <lang ada> protected body Event is

  procedure Signal is
  begin
     Fired := True;
  end Signal;
  procedure Reset is
  begin
     Fired := False;
  end Reset;
  entry Wait when Fired is
  begin
     null;
  end Wait;

end Event; </lang> With the event defined above: <lang ada> with Ada.Text_IO; use Ada.Text_IO;

procedure Test_Events is

  -- Place the event implementation here
  X : Event;
  task A;
  task body A is
  begin
     Put_Line ("A is waiting for X");
     X.Wait;
     Put_Line ("A received X");
  end A;

begin

  delay 1.0;
  Put_Line ("Signal X");
  X.Signal;

end Test_Events; </lang> Sample output:

A is waiting for X
Signal X
A received X