When two or more processes are able to update the value of a common data item, the possibility arises that the updates can interfere with and overwrite each other. An example is that of a variable that records the current balance of a customer account. Suppose the account has a current balance of $100. One process might have responsibility for subtracting $10 from the account. Another process, running simultaneously, might have responsibility for adding $15 to the account. The net result should be a balance of $105. However, the actual results can be quite different.
The problem arises because this type of update involves building on the value that is already present. If more than one process updates the account, a sequence like the following can occur:
-
Process A reads the account balance ($100) into variable A1.
-
Process B reads the account balance ($100) into variable B1.
-
Process A subtracts $10 from variable A1, leaving $90.
-
Process B adds $15 to variable B1, leaving $115.
-
Process A assigns the value from A1 to the account balance, leaving a balance of $90.
-
Process B assigns the value of B1 to the account balance, leaving a balance of $115.
In other words, process B can unintentionally delete the effect of the update performed by process A. The result is that the customer balance is left at $115 instead of the correct $105.
To prevent such situations from occurring, it is sometimes necessary that a process be able to secure exclusive access to an object for the duration of the transaction. The system provides a special type of variable called an event for handling these and other types of timing problems. You must use some means, such as global declarations, parameters, or SHAREDBYALL libraries, to provide the communicating processes with access to the event. You can then design the processes to use the event as a sort of flag to signal the availability of another object, such as a variable or file.
Events can be declared and used in ALGOL and COBOL. Certain implicitly declared events can also be accessed by WFL. For further information about events, refer to Using Events and Interlocks.
In addition to events, the system supports a synchronizing mechanism known as interlocks. You can use interlocks for some of the same purposes as events, but interlocks have the advantage of being executed more quickly. For further information about interlocks, refer to Using Interlocks in Using Events and Interlocks.
The system also supports two synchronization mechanisms based on the POSIX standards: signals and semaphores. These mechanisms serve a purpose similar to events, and are primarily useful for POSIX applications that are ported to the system. For further information, refer to the POSIX User's Guide.
