You can use the available state of an event to ensure that only one process has access to an object, or set of objects, at a time. This one-at-a-time access is sometimes referred to as mutual exclusion. You might need to ensure mutual exclusion for either of the following reasons:
-
To prevent updates made by one process from overwriting updates made by other processes. In this case, you need mutual exclusion only among processes that update an object.
-
To ensure that a set of related objects are updated, and consistency restored, before the next time a process reads any of those objects. This consistency can be important, for example, when table entries include cross-references to other table entries. In this case, you need mutual exclusion among all the processes that read or update the objects.
The available state of an event records whether the event is currently assigned to a process. An event can only be assigned to one process at a time. If the event is currently assigned to a process, the available state is NOT AVAILABLE. If the event is not assigned to a process, the available state is AVAILABLE. A procure statement is one that changes the available state from AVAILABLE to NOT AVAILABLE. A liberate statement is one that changes the available state to AVAILABLE.
To prevent two processes in a process family from accessing the same object at the same time, you declare an event that can be used by all the processes that access the object. The processes should be designed according to a common convention so that each attempts to procure the declared event before accessing the shared object. If the event cannot be procured immediately, the process should either wait for the event to become AVAILABLE or proceed with other business until the event becomes AVAILABLE. When a process is finished using the shared object, it should liberate the event and thus make the shared object available for use by other processes.
This mechanism of protecting a shared object depends on the cooperation of all the processes that access the object. The system is not aware of any link between the event and the object it protects.
Furthermore, procuring an event does not prevent other processes from accessing the event. It simply prevents other processes from directly procuring the event. These other processes could execute statements to liberate the event and then procure it, or execute statements that access the happened state. This fact allows considerable flexibility in the use of events.
