advanced operating systems fall 2009 lecture 8 wednesday february 4 2009 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009 PowerPoint Presentation
Download Presentation
Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009

Loading in 2 Seconds...

play fullscreen
1 / 23

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

  • Uploaded on

Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009. Dan C. Marinescu Email: 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Advanced Operating Systems - Fall 2009 Lecture 8 – Wednesday February 4, 2009' - ros

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
advanced operating systems fall 2009 lecture 8 wednesday february 4 2009
Advanced Operating Systems - Fall 2009Lecture 8 – Wednesday February 4, 2009
  • Dan C. Marinescu
  • Email:
  • Office: HEC 439 B.
  • Office hours: M, Wd 3 – 4:30.
last current next lecture
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
Synchronization Examples
  • Solaris
  • Windows XP
  • Linux
  • Pthreads
solaris synchronization
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
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
Linux Synchronization
  • Disables interrupts to implement short critical sections
  • Linux provides:
    • semaphores
    • spin locks
pthreads synchronization
Pthreads Synchronization
  • Pthreads API is OS-independent
  • It provides:
    • mutex locks
    • condition variables
  • Non-portable extensions include:
    • read-write locks
    • spin locks
atomic transactions
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
  • 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
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
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
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
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
non serial transaction schedule
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
locking protocol
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
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-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-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
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
  • 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.