The DD system is based on a set of fifos that are created and destroyed in real time. A process attaches to the DD system by creating a fifo from which he will read instances of the object Fifo_entry that describe the type and location of an event in shared memory. A process can become a producer by attaching to the a special fifo (called INPUT_FIFO) from where he will read instances of Fifo_entry, which are empty, but tell him the address of free space to copy an event.Events are only copied once into the DD shared memory. After that only instances of Fifo_entry are passed between the processes (i.e. written/read into/from the fifos). Once a process reads such a Fifo_entry from its fifo, the event ``disappears'' from the DD system until the process puts it back into the system. This allows modifcation of events (events can be compressed, merged or even deleted and newly created).
See the reference manual for a detailed description of the members of Fifo_entry.As it is not desirable that every process receives every event, a set of control words allow the routing of events directly to processes that ask for given event types. E787 uses the level 0 trigger bits as control words.
Processes can attach to the same fifo. In this case the events are shared between the processes. This allows to avoid bottlenecks by distributing the events between processes in a multiprocessor environment.
Fifos can be created and destroyed at any time. This enables e.g. user processes to attach to the DD system, receive a given number of events and then detach from it.
Four exceptions have to be handled within the DD system: When a process reads an empty fifo, when a process wants to write into a full fifo, when the system runs out of shared memory segments into which to place new events and when ``something really bad'' happens.
- Reading an empty fifo:
Every process specifies at initialisation time how the wants to handle this situation. He can either fall asleep until an event arrives or return with an error code or return with an error code and then receive a signal telling him, that an event has arrived.- Writing into a full fifo:
This situation is avoided by making the fifos deeper than the maximum number of possible events in the system.- The system runs out of shared memory segments:
This situation is identical to reading an empty fifo, whereas now the empty fifo is the INPUT_FIFO.- Something bad happens:
A demon constantly monitors the DD system and tries to detect and correct error conditions: E.g. if a processes crashes and doesn't detach from the DD system, it will be removed. Alternatively if there is a fatal error (i.e. the disappearance of shared memory segments or semaphores), the system is shut down as gracefully as it can be done.
Alphabetic index Hierarchy of classes