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

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

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 rolled back 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-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

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 conflict serializable 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 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)

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

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.