An Operating Systems Vade Mecum

Physical representation 2276.6 Implementing transactionsImplementing synchronization and failure atomicity is not easy. We will not give a verydetailed explanation here but will present some of the fundamental mechanisms that areused. To implement syncrhonization atomicity, the transaction manager may place ashared-access lock on files as they are opened for reading and an exclusive-access lockon files as they are opened for writing. (Instead of locking files, we can lock disks, directories,file records, or file bytes.) If the new lock conflicts with an existing lock held bysome other transaction, the transaction manager blocks the transaction that needs the newlock. These locks may be stored in the file descriptor by recording the transactionidentifiers of the holders of the lock. The two-phase locking policy requires that alllocks created by a transaction be maintained until the transaction is finished opening andclosing files. (During phase one, locks are acquired; during phase two, they arereleased.) This policy assures synchronization atomicity. However, the fact that Opencan block leads to a possibility of deadlock, so the transaction manager must be willing toabort a transaction.To implement failure atomicity, every time a change is made to a file, the state ofthe file before the transaction started may be saved. There are various ways to save theprevious state. One is to start a new file version every time a change is made; the versionis based on the time when the transaction started. If the transaction aborts, the previousversion can be used. Alternatively, all changes can be recorded in a log that includes theold state of the file before the change.A third alternative is to store all changes on fresh disk blocks. Those disk blocksare linked into the file descriptor only when the transaction is ready to complete. The listof operations needed to modify file descriptors is called an intentions list. Once the transactionis ready to complete, the intentions list is written. The transaction is then markedas committed. After this point, no failure will prevent completion of the transaction.The intentions are then performed. If the operating system should crash, it will redo theintentions when it starts up again. The intentions must be posed in such a way that doingthe same one many times has the same effect as doing it once.Correct implementation of transactions is complicated by the possibility that thedisk might fail. One way to make the disk more reliable is to build stable storage, whichcontains readable data even if the disk should fail in the middle of a write operation.Stable storage can be implemented by using two disk blocks. Writing to stable storageinvolves writing the same information to both blocks. Reading may use either one. If thedisk fails during a write operation, only one of those blocks can be injured; the other oneholds either the original data or the properly modified data. If the failure happensbetween the two writes, the one written first is believed. Stable storage can be used forany sensitive information. It is usually too costly to use for entire files, but it might beused for directory structures, logs, and intentions lists.If a transaction modifies files on several disks, there is a danger that some diskswill commit, but others will fail at the last minute and therefore maintain the old versions.The resulting chaos violates failure atomicity. To prevent this calamity, the two-phasecommit (not to be confused with two-phase locking) policy first writes the intentions listson all the disks (phase one), commits the transaction, and then starts performing theintentions (phase two). A disk failure during phase one aborts the entire transaction. Afailure during phase two causes no harm; the intentions will be performed later when the