230 likes | 418 Views
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.
E N D
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.
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 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
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 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 rolledback to undo any changes it performed
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
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 operationMultiple 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 transactionsExecution 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
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 conflictserializableIf S can become S’ via swapping nonconflicting operations
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 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)
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))
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
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.