COP 5611 Operating Systems Spring 2010 Dan C

COP 5611 Operating Systems Spring 2010 Dan C. Marinescu Office: HEC 439 B Office hours: M-Wd 1: 00 -2: 00 PM

Lecture April 5, 2010 n n Homework 3 due on Wednesday – April 14 Last time: ¨ n Today: ¨ n All or nothing atomicity Before or after atomicity Next time ¨ Conclude atomicity 2

Before or after atomicity n n n How to provide atomicity for concurrent actions? The version history mechanism does not prevent concurrent actions from accessing pending changes. The trivial solution – simple serialization The version history assigns a unique identifier to each atomic action to link tentative versions of a variable with the outcome record of the action. ¨ Now we require that the atomic actions are assigned consecutive integer values. ¨ Each newly created transaction, transaction n, must wait before reading or writing any shared variable until the previous (n-1) transactions have either committed or aborted. ¨ 3

Simple serialization requires a modified BEGIN_TRANSACTION

Serialization n Threads can still run in concurrently as serializations affects them only during the execution of transactions which handle shared variables. Relax the stringent requirement of serialization. Place dotted boxes for variables not affected by each transaction. 6

Mark-point discipline n n n Concurrent thread which invoke READ_CURRENT_VALUE should not see the PENDING version of any variable. A transaction can reveal all its results by changing the value of the OUTCOME record to COMMITTED. A transaction should also be able to wait for a PENDING value. Solution create pending values for all variables an application intends to modify and announce when it has finished this process Marking point the time when all pending values have been created Marking point discipline no transaction can begin reading its inputs until the preceding transactions has reached its marking point or is no longer pending. 8

READ_CURRENT_VALUE for the mark point discipline: 1. Skip all versions created by transaction later than the current transaction 2. Wait for a pending version created by an earlier transaction until that transaction either COMMITs or ABORTs

Mark-point discipline versions of: 1. NEW_VERSION 2. WRITE_VALUE 3. BEGIN_TRANSACTION 4. NEW_OUTCOME_RECORD

Mark-point version of the TRANSFER procedure

Optimistic atomicity n n Presume that interference between concurrent transactions is not likely. Allow the transactions to proceed without waiting. Watch for actual interference and take some recovery acction if it indeed happens. Read-capture discipline: A transaction does not need to predict the identity of every object it will update – it will discover the identity of these objects as it proceeds. ¨ When calling READ_CURRENT_VASLUE make a mark of the thread position in the version history. ¨ If a thread earlier in the serial ordering wants to insert but arrives late it must abort and try agaian using a later version in the version history. ¨ 13