COP 5611 Operating Systems Spring 2010

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

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

3. }

4. } }

6. Version history of one variable V from the journal storage

8. Outcome record • Created when the application calls the NEW_ACTION primitive of the journal storage manager call • It is created instate PENDING • When the application calls WRITE_NEW_VALUE of a data object it should supply • The identifier of the data object • The tentative new value • The identification of the all_or_nothing_action

9. Example of an outcome record

10. The state transitions of an outcome record

12. Algorithms to read the current value and write a new value If the current action fails before the COMMIT the new version of the variable is not visible to anyone wishing to read the current value. If an action changes multiple values but it fails before commit none of the modified values will be visible.

15. Atomicity logs The recording to the journal storage  optimized for speed of writing by creating a single interleaved version history of all variables. The writing to cell storage optimized for fast retrieval. The log is the authoritative record of the outcome of an action. The log resides in non-volatile storage

16. Write first to the journal and then to the cell storage

18. Logging protocols

19. Logging record • A log record contains the following information: • The identity of the action • A component action that if performed installs the intended value in cell storage • A component action which if performed reverses the effect of the action upon the cell storage • An application appends a log record by invoking the lower level primitive action LOG. • LOG is an atomic action itself

20. All-or-nothing TRANSFER with logging

21. Examples of two CHANGE records for a TRANSFER action with action_id=9979 and an OUTCOME record for action_id=9974

23. Recovery procedure • The recovery is function of the database layout • If an in-core database: • Two passes • First pass scan the log backwards from the last record (LIGO scan). Collect the identity and the completion status of all all_or_notingactions.The action which were either COMMITT-ed or ABORT-ed are called winners. • Forward scan  perform all the REDO actions

27. Before or after atomicity • 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 • Recall that 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.

28. Simple serialization requires a modified BEGIN_TRANSACTION

30. Serialization Threads can still run in concurrently as serializations affects them only during the execution of transactions which handle shared variables. Let see if we can relax the stringent requirement of serialization. Place dotted boxes for variables not affected by each transaction.

32. Mark-point discipline 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.

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

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

36. Mark-point version of the TRANSFER procedure

37. Optimistic atomicity • 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.