Event channels

Event channels provided the means for synchronizing programs in separate processes, or a program and an I-O device. They are a generalization of the semaphores of Dijkstra [D2]. One primitive which might have been used for synchronization is a test-and-set instruction. This has the deficiency that further primitives are needed to permit a process to block when attempting to access a locked data base. Also, there must be some procedure available for a process which unlocks the data base to discover what process, if any, should be awakened. Finally, we had no hardware test-and-set instruction. The semaphores of Dijkstra provide sufficient facilities to interlock a single data base [D2]. However, we felt that a major means of communication between distinct processes, or between a process and an I-O device, would be through a sequence of discrete messages. For example, a sequence of buffer loads could represent successive lines to be printed by a printer. Thus, we designed an event channel to communicate a stream of 60 bit data items. These items could be the indices of buffers which carried a more voluminous message. The basic actions available for event channels included: create, send-an-event, get-an-event, and destroy. The get-an-event action had four versions:

a)

get an event from an event channel, if no event waiting,

1)

return and so indicate, or

2)

block until one is available;

b)

get an event from one of several event channels, if no event waiting on any of them,

1)

return and so indicate

2)

block until one is available on one of the channels.

One major problem with event channels was a restriction we imposed: the waiting events must be recorded in a fixed region for each event channel. (The size of this region was specified when the event channel was created.) This imposed a maximum limit on the number of waiting events an event channel could hold. After this point, an attempt to send an event to a full event channel returned with a refusal. This problem was helped by providing that when the last possible event was sent to an event channel, it was automatically converted to a special one, and the sender informed. Then, a program receiving one of these special events had to communicate with possible senders, to straighten things out. In general, this was moderately difficult. There was no limit on the number of processes which could be blocked, waiting for an event to arrive at a given event channel.