Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009 Dan C. Marinescu Email: dcm@cs.ucf.edu Office: HEC 439 B. Office hours: M, Wd 3 – 4:30.

Last, Current, Next Lecture Last time: Discussion of a problem regarding threads and I/O. More about condition variables and monitors Discussion of a problem about condition variables and monitors. Today Discussion of homework assignment 3 Process synchronization leftovers Atomic transactions Discussion of a problem about atomic transactions Next time: Deadlocks

Synchronization Examples Solaris Windows XP Linux Pthreads

Solaris Synchronization Implements a variety of locks to support multitasking, multithreading (including real-time threads), and multiprocessing Uses adaptive mutexes for efficiency when protecting data from short code segments condition variables and readers-writers locks when longer sections of code need access to data turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock

Windows XP Synchronization To protect global resources uses interrupt masks on uniprocessor systems spinlocks on multiprocessor systems Provides dispatcher objects which may act as either mutexes and semaphores Dispatcher objects may also provide events. An event acts much like a condition variable

Linux Synchronization Disables interrupts to implement short critical sections Linux provides: semaphores spin locks

Pthreads Synchronization Pthreads API is OS-independent It provides: mutex locks condition variables Non-portable extensions include: read-write locks spin locks

Atomic Transactions System Model Log-based Recovery Checkpoints Transaction  collection of instructions or operations that performs single logical function. Atomic transactions   transactions are guaranteed to either completely occur, or have no effects. Problem  How to ensure atomicity in spite of system failures System Model Log-based Recovery Checkpoints Concurrent Atomic Transactions

Storage Volatile  information stored does not survive system crashes. Example: main memory, cache Nonvolatile Information usually survives crashes. Example: disk, tape, optical media. Stable  information never lost. Not actually possible; approximated via replication or RAID to devices with independent failure modes

System Model Assures that operations happen as a single logical unit of work, in its entirety, or not at all We are concerned with changes to stable storage – disk. Series of read and write operations terminated by commit (transaction successful) or abort (transaction failed) operation Aborted transaction must be rolled back to undo any changes it performed

Log-Based Recovery Record to stable storage information about all modifications by a transaction Most common is write-ahead logging on stable storage: A log record describes single transaction write operation, including Transaction name Data item name Old value New value <Ti starts>  written to log when transaction Ti starts <Ti commits>  written to log when Ti commits Log entry must reach stable storage before operation on data occurs

Log-Based Recovery Algorithm Using the log, system can handle any volatile memory errors Undo(Ti) restores value of all data updated by Ti Redo(Ti) sets values of all data in transaction Ti to new values Undo(Ti) and Redo(Ti) must be idempotent Idempotent operationMultiple executions of the operation must have the same result as one execution If system fails, restore state of all updated data using the log If log contains <Ti starts> without <Ti commits>, undo(Ti ) If log contains <Ti starts> and <Ti commits>, redo(Ti)

Concurrent transactions. Serializability Perform concurrent transactions in a critical section  too restrictive Consider two data items A and B transactions T0 and T1 Execute T0, T1 atomically Schedule of transactions Execution sequence of transactions Serializability of a transaction schedule: if its outcome (the resulting database state, the values of the database's data) is equal to the outcome of its transactions executed serially, Serial schedule: order of atomically executed transactions For N transactions, there are N! valid serial schedules Concurrency-control algorithms provide serializability

Schedule 1: T0 then T1

Non-serial Transaction Schedule Non-serial schedule  allows overlapped execute. Resulting execution not necessarily incorrect. Schedule S has a conflict if operations O1, O2 access the same data item, and there is at least one write. If operations O1, O2 are consecutive and the operations of different transactions involving O1 and O2 don’t conflict then there is a schedule S’ with swapped order of operations O1 and O2 equivalent to S S is conflict serializable If S can become S’ via swapping nonconflicting operations

Schedule 2: Concurrent Serializable Schedule

Locking Protocol Ensure serializability by associating lock with each data item. Follow locking protocol for access control. Locks Shared – T has shared-mode lock (S) on item Q can read Q but not write Q Exclusive – T has exclusive-mode lock (X) on Q  can read and write Q Every transaction on item Q must acquire appropriate lock If lock already held, new request may have to wait. Similar to readers-writers algorithm

Two-phase Locking Protocol Generally ensures conflict serializability Each transaction issues lock and unlock requests in two phases Growing  obtain locks Shrinking  release locks Does not prevent deadlock

Timestamp-based Protocols Timestamp-ordering: select order among transactions in advance. TS(a) timestamp of transaction a associated TS(a). TS(a) < TS(b) if transaction a entered system before b The timestamp can be: generated from system clock or a counter incremented at each entry of transaction Timestamps determine serializability order If TS(a) < TS(b) then the system must produce a schedule equivalent to the serial schedule where TS(a) appears before TS(b)

Timestamp-based Protocol Implementation Timestamp-ordering protocol  assures conflicting read and write executed in timestamp order Data item Q gets two timestamps W-timestamp(Q) – largest timestamp of any transaction that executed write(Q) successfully R-timestamp(Q) – largest timestamp of successful read(Q) Updated whenever read(Q) or write(Q) executed Suppose T executes read(Q) If TS(T) < W-timestamp(Q), T needs to read value of Q that was already overwritten read operation rejected and T rolled back If TS(T) ≥ W-timestamp(Q) read executed, R-timestamp(Q) set to max(R-timestamp(Q), TS(Ti))

Timestamp-ordering Protocol Transaction a executes: write(Q) If TS(a) < R-timestamp(Q), value Q produced by a was needed previously and a assumed it would never be produced Write operation rejected, a rolled back If TS(a) < W-timestamp(Q), a attempting to write obsolete value of Q Write operation rejected and a rolled back Otherwise, write executed Any rolled back transaction a is assigned new timestamp and restarted Algorithm ensures conflict serializability and freedom from deadlock

Schedule Possible Under Timestamp Protocol

Problem In electronic funds transfer consider a transaction involving two accounts at two banks linked by a network. Describe a protocol that ensures the correctness of the transactions for several failure scenarios at different stages of transaction processing: The system at the bank with one of the accounts fails; One of the systems and the network fail; Both systems and the network fail independently.