Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009

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

2. 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

3. Synchronization Examples • Solaris • Windows XP • Linux • Pthreads

4. 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 variablesand 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

5. 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

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

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

8. Atomic Transactions 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

9. 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

10. 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 rolledback to undo any changes it performed

11. Log-Based Recovery • Record to stable storage information about all modifications by a transaction • Most common is write-aheadlogging 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 Tistarts • <Ti commits>  written to log when Ticommits • Log entry must reach stable storage before operation on data occurs

12. 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)

13. 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

14. Schedule 1: T0 then T1

15. 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 conflictserializableIf S can become S’ via swapping nonconflicting operations

16. Schedule 2: Concurrent Serializable Schedule

17. 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

18. 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

19. Timestamp-based Protocols • Timestamp-ordering: select order among transactions in advance. • TS(a) timestamp of transaction aassociated 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)

20. Timestamp-based Protocol Implementation • Timestamp-orderingprotocol 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))

21. 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

22. Schedule Possible Under Timestamp Protocol

23. 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.