The design of the I/O hardware prevents any two I/O operations from accessing the same record at the same time. For example, there is no way for a record to be read when a write operation involving the same record is half completed. The read operation is delayed until the write operation finishes.
However, you can prevent other types of synchronization problems only through careful program design. Note that these synchronization concerns arise only in cases where at least one of the processes writes to the shared file. If all the processes simply read from the file, then the order in which they execute their read operations makes no difference. The following are the basic goals of synchronization:
-
For cases where one process writes to a particular record and a second process is to read the updated record, the second process should wait until the record is updated before reading it.
-
For cases where two processes read and update the same record, the processes should be prevented from accidentally overwriting each other's updates. Such overwriting can occur if both processes read from the record and then both processes write to the record. The second write operation erases the effects of the first, and information can therefore be lost. A mechanism must be established to ensure that the first process completes its update of the record before the second process reads it.
These types of synchronization can be achieved conveniently through the use of events. Events can be shared between processes in the same way that logical files are shared: they can be accessed as global objects by internal tasks, passed as call-by-reference parameters, or accessed through a SHAREDBYALL library.
If it is only necessary to ensure that different processes do not update the file at the same time, the available state of an event can be used. Each process can be designed to procure the event before using the file, and liberate the event afterward.
If it is necessary to ensure that processes access a file in a certain order, the happened state of an event can be used. The second process that is to use the file can wait on an event. When the first process is finished using the file, the process can cause the event.
