1 / 23

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

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.

ros
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related