An Operating Systems Vade Mecum

212 File Structures Chapter 6Synchronization atomicityEach transaction should appear to be atomic, that is, indivisible, without interference from other transactions that might be occurring at the same time. The simplest form of synchronization atomicity applies to transactions on only one file.If process A is modifying a file F in several places, but process B is reading F, we wouldlike B’s view of F either to omit any of A’s modifications or to include them all. In mostoperating systems, this result is achieved by preventing A and B from opening the file atthe same time. This policy enforces strict serialization on accesses to the same file.Not all simultaneous file accesses lead to failures of synchronization atomicity.There is no problem with any number of processes opening the file for reading. Theproblem occurs only if one process wishes to write when some other process wants toread or write. This set of constraints is commonly known as the readers-writers problem.We will see this problem again in Chapter 7 when we discuss process synchronization.The constraints of the readers-writers problem are shown in the following table:ReadWriteRead permissible Read/Write conflictWrite Read/Write conflict Write/Write conflictMany operating systems prevent any process from opening a file that is alreadyopen for writing (by any process). A file open for reading may not be opened for writing.This policy prevents any of the conflicts of the readers-writers problem. If the filemanager does not provide this service, it can be awkward or impossible to build it out ofother services that are provided.In BSD4.2 Unix, file interlock is optional. Processes can open files requestingeither exclusive or shared access to the file. Shared access is intended for processes thatonly want to read the file. Exclusive access is for those that want to modify the file.While a file is open with exclusive access, no process is allowed to open it with shared orexclusive access. While a file is open with shared access, no process is allowed to open itwith exclusive access. However, a process may violate the rules by opening the filewithout specifying either shared or exclusive access. In VMS, individual records ofstructured files may be locked separately.A transaction may involve several files. Most operating systems do not providesynchronization atomicity in such cases. However, we can provide this feature for databaseutilities that need it. Instead of forcing the file manager to undertake this task, wewill speak of a transaction manager in the kernel that handles complex cases.To provide synchronization atomicity in such cases, the transaction manager mustknow when a transaction starts and when it finishes. Every open file may be associatedwith some transaction. We could automatically start a transaction every time a user startsa session and associate all file actions during that session with the same transaction.However, this policy would lead to needlessly long transactions that would interfere withother users. Instead, it is better to let a process open a transaction, much as it might open