OSes: 5. Synch 1

Operating SystemsOperating Systems

ObjectivesObjectives– describe the synchronization problem and describe the synchronization problem and

some common mechanisms for solving itsome common mechanisms for solving it

Certificate Program in Software DevelopmentCSE-TC and CSIM, AITSeptember -- November, 2003

5. Process Synchronization(Ch. 6, S&G)

ch 7 in the 6th ed.

OSes: 5. Synch 2

ContentsContents

1.1. Motivation: Bounded BufferMotivation: Bounded Buffer

2.2. Critical SectionsCritical Sections

3.3. Synchronization HardwareSynchronization Hardware

4.4. SemaphoresSemaphores

5.5. Synchronization ExamplesSynchronization Examples

continued

OSes: 5. Synch 3

6.6. Problems with SemaphoresProblems with Semaphores

7.7. Critical RegionsCritical Regions

8.8. MonitorsMonitors

9.9. Synchronization in Solaris 2 Synchronization in Solaris 2

10.10. Atomic TransactionsAtomic Transactions

OSes: 5. Synch 4

1. Motivation: Bounded Buffer1. Motivation: Bounded Buffer

0 1 2 3 n-1

…..

…..

producer consumerwrite read

bounded buffer

OSes: 5. Synch 5

Producer Code (pseudo-Pascal)Producer Code (pseudo-Pascal)

:repeat . . . /* produce an itemP */ . . . while (counter == n) do no-op; buffer[in] := itemP; /* write */ in := (in+1) mod n; counter := counter + 1;until false;

:

OSes: 5. Synch 6

Consumer CodeConsumer Code

:repeat while (counter == 0) do no-op; itemC := buffer[out]; /* read */ out := (out+1) mod n; counter := counter - 1; . . . /* use itemC for something */ . . .until false;

:

OSes: 5. Synch 7

ProblemProblem

Assume Assume counter == 5

producerproducer run run consumer runconsumer run: :

counter := counter := counter + 1; counter - 1;

: :

countercounter may now be may now be 44, , 55, or , or 66. . Why?Why?

OSes: 5. Synch 8

Machine LanguageMachine Language

““counter := counter + 1”counter := counter + 1” becomes: becomes:reg1 := counterreg1 := reg1 + 1counter := reg1

““counter := counter - 1”counter := counter - 1” becomes: becomes:reg2 := counterreg2 := reg2 - 1counter := reg2

OSes: 5. Synch 9

Execution InterleavingExecution Interleaving

The concurrent execution of the two The concurrent execution of the two processes is achieved by interleaving the processes is achieved by interleaving the execution of eachexecution of each

There are many possible interleavings, There are many possible interleavings, which can lead to different values for which can lead to different values for countercounter

– a different interleaving may occur each time a different interleaving may occur each time the processes are runthe processes are run

OSes: 5. Synch 10

Interleaving ExampleInterleaving Example

Initially: Initially: counter == 5counter == 5

Execution:Execution:reg1 := counter // reg1 == 5reg1 := reg1 + 1 // reg1 == 6reg2 := counter // reg2 == 5reg2 := reg2 - 1 // reg2 == 4counter := reg1 // counter == 6counter := reg2 // counter == 4

OSes: 5. Synch 11

Summary of ProblemSummary of Problem

Incorrect results occur because of aIncorrect results occur because of a race race conditioncondition over the modification of the over the modification of the shared variable (shared variable (countercounter))

The processes must be The processes must be synchronizedsynchronized while while they are sharing data so that the result is they are sharing data so that the result is predictable and correctpredictable and correct

OSes: 5. Synch 12

2. Critical Sections2. Critical Sections

A critical section is a segment of code A critical section is a segment of code which can only be executed by one process which can only be executed by one process at a timeat a time– all other processes are excludedall other processes are excluded– called called mutual exclusionmutual exclusion

OSes: 5. Synch 13

Critical Section Pseudo-codeCritical Section Pseudo-code

repeat entry section

critical section

exit section

remainder sectionuntil false;

OSes: 5. Synch 14

Implementation FeaturesImplementation Features

An implementation of the critical section An implementation of the critical section idea must have three features:idea must have three features:– mutual exclusionmutual exclusion– progressprogress

the next process to enter the critical region is the next process to enter the critical region is decided solely by looking at those waiting in their decided solely by looking at those waiting in their entry sectionsentry sections

– bounded waitingbounded waiting no process should wait forever in their entry sectionno process should wait forever in their entry section

OSes: 5. Synch 15

2.1. Solutions for Two Processes2.1. Solutions for Two Processes

Algorithm 1 (take turns)Algorithm 1 (take turns)– shared data:shared data:

var turn: 0..1 := 0; /* or 1 */

– Code for process i:Code for process i: repeat while (turn /== i) do no-op: critical section; turn := j; remainder section;until false; progress requirement

not met

OSes: 5. Synch 16

Algorithm2Algorithm2 (who wants to enter?)(who wants to enter?)

Shared data:Shared data:var flag : array [0..1] of boolean

:= {false, false};

Code for process i:Code for process i:repeat flag[i] := true; while (flag[j]) do no-op: critical section; flag[i] := false; remainder section;until false; progress requirement

still not met

OSes: 5. Synch 17

Algorithm 3Algorithm 3 (Peterson, 1981) (Peterson, 1981)

Combines algorithms 1 and 2Combines algorithms 1 and 2– who wants to enter?who wants to enter?– if both do then take turnsif both do then take turns

Shared data:Shared data:var flag : array [0..1] of boolean

:= {false, false};

var turn : 0..1 := 0; /* or 1 */

continued

OSes: 5. Synch 18

Code for process i:Code for process i:repeat flag[i] := true; turn := j; while (flag[j] and turn == j) do no-op: critical section; flag[i] := false; remainder section;until false;

OSes: 5. Synch 19

2.2. Multiple Processes2.2. Multiple Processes

Uses the Uses the bakery algorithmbakery algorithm (Lamport 1974). (Lamport 1974).

Each customer (process) receives a number Each customer (process) receives a number on entering the store (the entry section).on entering the store (the entry section).

The customer with the lowest number is The customer with the lowest number is served first (enters the critical region).served first (enters the critical region).

continued

OSes: 5. Synch 20

If two customers have the same number, If two customers have the same number, then the one with the lowest name is served then the one with the lowest name is served firstfirst– names are unique and orderednames are unique and ordered

OSes: 5. Synch 21

Pseudo-codePseudo-code

Shared data:Shared data:var choosing : array [0..n-1]

of boolean:= {false .. false};

var number : array [0..n-1] of integer

:= {0 .. 0};

continued

OSes: 5. Synch 22

Code for process i:Code for process i:repeat choosing[i] := true; number[i] := max(number[0], number[1],

. . ., number[n-1]) + 1; choosing[i] := false; for j := 0 to n-1 do begin while (choosing[j]) do no-op; while ((number[j] /== 0) and ((number[j],j) < (number[i],i))) do no-op; end; critical section number[i] := 0; remainder sectionuntil false;

OSes: 5. Synch 23

3. Synchronization Hardware3. Synchronization Hardware

Hardware solutions can make software Hardware solutions can make software synchronization much simplersynchronization much simpler

On a uniprocessor, the OS can disallow On a uniprocessor, the OS can disallow interrupts while a shared variable is being interrupts while a shared variable is being changedchanged– not so easy on multiprocessorsnot so easy on multiprocessors

continued

OSes: 5. Synch 24

Typical hardware support:Typical hardware support:– atomic test-and-set of a boolean (byte)atomic test-and-set of a boolean (byte)– atomic swap of booleans (bytes)atomic swap of booleans (bytes)

Atomic means an uninterruptable ‘unit’ of Atomic means an uninterruptable ‘unit’ of work.work.

OSes: 5. Synch 25

3.1. Atomic Test-and-Set3.1. Atomic Test-and-Set

function Test-and-Set( var target : boolean) : boolean

begin Test-and-Set := target; target := true;end;

OSes: 5. Synch 26

UseUse Shared data:Shared data:

var lock : boolean := false;

Process code for mutual exclusion:Process code for mutual exclusion:repeat while (Test-and-Set(lock) do no-op; critical section lock := false; remainder sectionuntil false;

lock/in lock/out result action F T F proceed T T T loop

OSes: 5. Synch 27

3.2. Atomic Swap3.2. Atomic Swap

procedure Swap(var a, b : boolean)var temp : boolean;begin temp := a; a := b; b := temp;end;

OSes: 5. Synch 28

UseUse Shared data:Shared data:

var lock : boolean := false;

Process code for m.e.:Process code for m.e.:var key : boolean:repeat key := true; repeat Swap(lock, key); until (key == false); critical section lock := false; remainder sectionuntil false;

key1 key2 … keyN lockin: T T … T F

OSes: 5. Synch 29

3.3. Bounded Waiting3.3. Bounded Waiting

TestAndSet() and Swap() both satisfy the TestAndSet() and Swap() both satisfy the requirements of mutual exclusion and requirements of mutual exclusion and progressprogress

But bounded waiting is But bounded waiting is notnot satisfied satisfied

We must add an extra data structure to code We must add an extra data structure to code FIFO (queueing-style) behaviourFIFO (queueing-style) behaviour

OSes: 5. Synch 30

4. Semaphores4. Semaphores (Dijkstra, 1965)(Dijkstra, 1965)

Semaphores are a synchronization tool Semaphores are a synchronization tool based around two atomic operations:based around two atomic operations:

– wait()wait() sometimes called sometimes called P()P()

– signal()signal() sometimes called sometimes called V()V()

OSes: 5. Synch 31

4.1. Definitions4.1. Definitions

procedure wait(var S : semaphore)begin while (S =< 0) do no-op; S := S - 1; end;

procedure signal(var S : semaphore)begin S := S + 1; end;

same as integer

OSes: 5. Synch 32

4.2. Mutual Exclusion with Semaphores4.2. Mutual Exclusion with Semaphores

Shared data:Shared data:var mutex : semaphore := 1;

Process code:Process code:repeat wait(mutex); critical section; signal(mutex); remainder section;until false;

OSes: 5. Synch 33

4.3. Ordering Processes4.3. Ordering Processes

Establish a fixed order for two processes Establish a fixed order for two processes pp11 and p and p22 , We set semaphore , We set semaphore Order := 0Order := 0..

If the desired order is pIf the desired order is p11 -> p -> p22, p, p22 should should

issue a issue a wait(Order)wait(Order), and then wait until p, and then wait until p11

issues a issues a signal(Order)signal(Order)..

OSes: 5. Synch 34

4.4. Counting Semaphores4.4. Counting Semaphores

Allow N processes into a critical section, by Allow N processes into a critical section, by initialising semaphore initialising semaphore LimitLimit to to NN – the first N processes each decrement the first N processes each decrement LimitLimit

using using wait(Limit)wait(Limit), until , until Limit == 0Limit == 0, at , at which time new processes must waitwhich time new processes must wait

This approach is used for controlling access This approach is used for controlling access to a limited number of resources (e.g. N to a limited number of resources (e.g. N resources) resources)

OSes: 5. Synch 35

4.5. Implementations4.5. Implementations

Our Our wait()wait() implementation uses busy-waiting implementation uses busy-waiting– sometimes called a sometimes called a spinlockspinlock

An alternative is for the process calling An alternative is for the process calling wait()wait() to to blockblock– place itself on a wait list associated with the place itself on a wait list associated with the

semaphoresemaphore– signal()signal() chooses a blocked process to become ready chooses a blocked process to become ready

OSes: 5. Synch 36

New Semaphore Data TypeNew Semaphore Data Type

type semaphore = record value : integer; L : list of waiting-

processes;end;

OSes: 5. Synch 37

New OperationsNew Operations

procedure wait(var S : semaphore)begin S.value := S.value - 1; if (S.value < 0) then begin /* add the calling process to S.L */ . . . block; end;end;

continued

OSes: 5. Synch 38

procedure signal(var S : semaphore)begin S.value := S.value + 1; if (S.value =< 0) then begin /* remove a process P from S.L */ . . . wakeup(P); end;end;

OSes: 5. Synch 39

4.6. Deadlocks & Starvation4.6. Deadlocks & Starvation

DeadlockDeadlock occurs when every process is occurs when every process is waiting for a waiting for a signal(S)signal(S) call that can only be call that can only be carried out by one of the waiting processes.carried out by one of the waiting processes.

StarvationStarvation occurs when a waiting process occurs when a waiting process never gets selected to move into the critical never gets selected to move into the critical region.region.

OSes: 5. Synch 40

4.7. Binary Semaphores4.7. Binary Semaphores

A A binary semaphorebinary semaphore is a specialisation of is a specialisation of the counting semaphore with S only having the counting semaphore with S only having a range of 0..1a range of 0..1– S starts at 0S starts at 0– easy to implementeasy to implement– can be used to code up counting semaphorescan be used to code up counting semaphores

OSes: 5. Synch 41

5. Synchronization Examples5. Synchronization Examples

5.1. Bounded Buffer5.1. Bounded Buffer

5.2. Readers and Writers5.2. Readers and Writers

5.3. Dining Philosophers5.3. Dining Philosophers

OSes: 5. Synch 42

5.1. Bounded Buffer (Again)5.1. Bounded Buffer (Again)

0 1 2 3 n-1

…..

…..

producer consumerwrite read

bounded buffer

OSes: 5. Synch 43

ImplementationImplementation

Shared data:Shared data:var buffer : array[0..n-1] of Item;

var mutex : semaphore := 1;/* for access to buffer */

var full : semaphore := 0;/* num. of used array cells */

var empty : semaphore := n;/* num. of empty array cells

*/

OSes: 5. Synch 44

Producer CodeProducer Code

repeat . . . /* produce an itemP */ . . . wait(empty); wait(mutex); buffer[in] := itemP; in := (in+1) mod n; signal(mutex); signal(full);until false;

OSes: 5. Synch 45

Consumer CodeConsumer Code

repeat wait(full); wait(mutex); itemC := buffer[out]; out := (out+1) mod n; signal(mutex); signal(empty); . . . /* use itemC for something */ . . .until false;

OSes: 5. Synch 46

5.2. Readers & Writers5.2. Readers & Writers

Readers make no change to the shared data Readers make no change to the shared data (e.g. a file)(e.g. a file)– no synchronization problemno synchronization problem

Writers do change the shared dataWriters do change the shared data

Multiple writers (or a writer Multiple writers (or a writer andand readers) readers) cause a synchronization problem. cause a synchronization problem.

OSes: 5. Synch 47

Many VariationsMany Variations

1. Don’t keep a reader waiting unless a 1. Don’t keep a reader waiting unless a writer is already using the shared datawriter is already using the shared data– writers may starvewriters may starve

2. Don’t keep a writer waiting2. Don’t keep a writer waiting– readers may starvereaders may starve

OSes: 5. Synch 48

Variation 1Variation 1 Shared data:Shared data:

var shared-data : Item;

var readcount : integer : = 0;/* no. of readers currently

using shared-data */

var mutex : semaphore := 1;/* control access to readcount */

var wrt : semaphore := 1;/* used for m.e. of writers */

OSes: 5. Synch 49

Writer’s CodeWriter’s Code

:wait(wrt);. . ./* writing is performed */. . .signal(wrt);

:

OSes: 5. Synch 50

Reader’s CodeReader’s Code

wait(mutex); readcount := readcount + 1; if (readcount == 1) then wait(wrt);signal(mutex);. . ./* reading is performed */. . .wait(mutex); readcount := readcount - 1; if (readcount == 0) then signal(wrt);signal(mutex);

OSes: 5. Synch 51

5.3. Dining Philosophers5.3. Dining Philosophers

An example of the An example of the need to allocate several need to allocate several resources (chopsticks) resources (chopsticks) among processes among processes (philosophers) in a (philosophers) in a deadlock and deadlock and starvation free manner.starvation free manner.

Dijkstra, 1965

OSes: 5. Synch 52

ImplementationImplementation Represent each chopstick by a semaphore.Represent each chopstick by a semaphore.

Shared data:Shared data:var chopstick : array[0..4]

of semaphore:= {1,1,1,1,1};

A chopstick is ‘picked up’ with: A chopstick is ‘picked up’ with: wait(chopstick[pos])wait(chopstick[pos])

and ‘set down’ with:and ‘set down’ with:

signal(chopstick[pos])signal(chopstick[pos])

OSes: 5. Synch 53

Code for Philopospher iCode for Philopospher i

repeat wait( chopstick[i] ); wait( chopstick[(i+1) mod 5] );

/* . . . eat . . . */

signal( chopstick[i] ); signal( chopstick[(i+1) mod 5] );

/* . . . think . . . */until false;

OSes: 5. Synch 54

DeadlockDeadlock

This solution avoids simultaneous use of This solution avoids simultaneous use of chopsticks (chopsticks (goodgood))

But if all the philosophers pick up their left But if all the philosophers pick up their left chopstick together, then they will chopstick together, then they will deadlockdeadlock while waiting for access to their right while waiting for access to their right chopstick.chopstick.

OSes: 5. Synch 55

Possible FixesPossible Fixes

Allow at most 4 philosophers to be at the table at Allow at most 4 philosophers to be at the table at a time.a time.

Have a philosopher pick up their chopsticks only Have a philosopher pick up their chopsticks only if both are available (in a critical section) if both are available (in a critical section)

Alternate the order that chopsticks are picked up Alternate the order that chopsticks are picked up depending on whether the philosopher is seated at depending on whether the philosopher is seated at an odd or even seatan odd or even seat

OSes: 5. Synch 56

6. Problems with Semaphores6. Problems with Semaphores

The reversal of a The reversal of a wait()wait() and and signal()signal() pair pair will break mutual exclusionwill break mutual exclusion

The omission of either a The omission of either a wait()wait() or or signal()signal() will potentially cause deadlockwill potentially cause deadlock

These problems are difficult to debug and These problems are difficult to debug and reproducereproduce

OSes: 5. Synch 57

Higher level SynchronizationHigher level Synchronization

These problems have motivated the These problems have motivated the introduction of higher level constructs:introduction of higher level constructs:– critical regions critical regions – monitorsmonitors– condition variablescondition variables

These constructs are safer, and easy to These constructs are safer, and easy to understandunderstand

OSes: 5. Synch 58

7. Critical Regions7. Critical Regions

Shared variables are explicitly declared:Shared variables are explicitly declared:var v : var v : sharedshared ItemType; ItemType;

A shared variable can only be accessed within A shared variable can only be accessed within the code part (the code part (SS) of a ) of a regionregion statement: statement:

region v do Sregion v do S

– while code while code SS is being executed, no other process is being executed, no other process can access can access vv

Hoare, 1972;Brinch Hansen, 1972

OSes: 5. Synch 59

Conditional Critical RegionsConditional Critical Regions

region v when B do Sregion v when B do S

– only execute only execute SS when the boolean expression when the boolean expression BB evaluates to true, otherwise wait until evaluates to true, otherwise wait until BB is true is true

– as before, while code as before, while code SS is being executed, no is being executed, no other process can access other process can access vv

OSes: 5. Synch 60

Bounded Buffer AgainBounded Buffer Again

Shared data:Shared data:

var buffer : shared recordpool : array[0..n-1] of Item;count, in, out : integer;

end;

OSes: 5. Synch 61

Producer CodeProducer Code

region buffer when (count < n) dobegin pool[in] := itemP; in := (in+1) mod n; count := count + 1;end;

OSes: 5. Synch 62

Consumer CodeConsumer Code

region buffer when (count > 0) dobegin itemC := pool[out]; out := (out+1) mod n; count := count - 1;end;

OSes: 5. Synch 63

8. Monitors8. Monitors Brinch Hansen, 1973

shared data

initializationcode

operations

varqueues associatedwith conditionvariables entry queue of

waiting processes

Fig. 6.20, p.184

OSes: 5. Synch 64

Monitor SyntaxMonitor Syntax

type monitor-name = monitor variable declarations

procedure entry p1(. . .) begin . . . end;

:

begin initialization codeend.

OSes: 5. Synch 65

FeaturesFeatures When an instance of a monitor is created, When an instance of a monitor is created,

its initialization code is executedits initialization code is executed

A procedure can access its own variables A procedure can access its own variables and those in the monitor’s variable and those in the monitor’s variable declarationsdeclarations

A monitor only allows one process to use A monitor only allows one process to use its operations at a timeits operations at a time

OSes: 5. Synch 66

An OO View of MonitorsAn OO View of Monitors

A monitor is similar to a classA monitor is similar to a class

An instance of a monitor is similar to an An instance of a monitor is similar to an object, with all private dataobject, with all private data

PlusPlus synchronization: invoking any synchronization: invoking any operation (method) results in mutual operation (method) results in mutual exclusion over the entire objectexclusion over the entire object

OSes: 5. Synch 67

8.1. Condition Variables8.1. Condition Variables

Notation:Notation:var x : condition;var x : condition;

x.wait;x.wait; suspend calling processsuspend calling process

x.signal;x.signal; resumes one of the suspended resumes one of the suspended

processes waiting on processes waiting on xx

OSes: 5. Synch 68

Condition Variables in MonitorsCondition Variables in Monitors What happens when What happens when signalsignal is issued? is issued?

The unblocked process will be placed on The unblocked process will be placed on the ready queue and resume from the the ready queue and resume from the statement following the statement following the waitwait..

This This wouldwould violate mutual exclusion violate mutual exclusion ifif both both the signaller and signalled process are the signaller and signalled process are executing in the monitor at once.executing in the monitor at once.

OSes: 5. Synch 69

Three Possible SolutionsThree Possible Solutions

1. Have the signaller leave the monitor 1. Have the signaller leave the monitor immediately after calling immediately after calling signalsignal

2. Have the signalled process wait until the 2. Have the signalled process wait until the signaller has left the monitorsignaller has left the monitor

3. Have the signaller wait until the 3. Have the signaller wait until the signalled process has left the monitorsignalled process has left the monitor

OSes: 5. Synch 70

8.2. Dining Philosophers (Again)8.2. Dining Philosophers (Again)

Useful data structures:Useful data structures:var state : array[0..4] of

(thinking, hungry, eating);var self : array[0..4] of condition;

/* used to delay philosophers */

The approach is to only set The approach is to only set state[i]state[i] to to eatingeating if its two neigbours are not eatingif its two neigbours are not eating– i.e. i.e. state[(i+4) mod 5] state[(i+4) mod 5] == eating eating

andand state[(i+1) mod 5] state[(i+1) mod 5] == eating eating

OSes: 5. Synch 71

Using the dining-philosophers MonitorUsing the dining-philosophers Monitor

Shared data:Shared data:var dp : dining-philosopher;

Code in philosopher i:Code in philosopher i:dp.pickup(i):/* . . . eat . . . */dp.putdown(i);

OSes: 5. Synch 72

Monitor implementationMonitor implementation

type dining-philosophers = monitor var state : array[0..4] of

(thinking, hungry, eating); var self : array[0..4] of condition;

procedure entry pickup(i : 0..4) begin state[i] := hungry; test(i); if (state[i] /== eating) then self[i].wait; end;

continued

OSes: 5. Synch 73

procedure entry putdown(i : 0..4) begin state[i] := thinking; test((i+4) mod 5); test((i+1) mod 5); end;

continued

OSes: 5. Synch 74

procedure test(k : 0..4) begin if ((state[(k+4) mod 5] /== eating)

and (state[k] == hungry) and (state[(k+1) mod 5]

/== eating)) then begin state[k] := eating; self[k].signal; end; end;

continued

OSes: 5. Synch 75

begin /* initialization of monitor instance */ for i := 0 to 4 do state[i] := thinking;end.

OSes: 5. Synch 76

8.3. Problems with Monitors8.3. Problems with Monitors

Even high level operations can be misused.Even high level operations can be misused.

For correctness, we must check:For correctness, we must check:– that all user processes always call the monitor that all user processes always call the monitor

operations in the right order;operations in the right order;– that no user process bypasses the monitor and that no user process bypasses the monitor and

uses a shared resource directlyuses a shared resource directly– called the called the access-control problemaccess-control problem

OSes: 5. Synch 77

9. Synchronization in Solaris 29. Synchronization in Solaris 2

Uses a mix of techniques:Uses a mix of techniques:– semaphores using spinlockssemaphores using spinlocks

– thread blockingthread blocking

– condition variables (without monitors)condition variables (without monitors)

– specialised reader-writer locks on dataspecialised reader-writer locks on data

OSes: 5. Synch 78

10. Atomic Transactions10. Atomic Transactions We want to do all the operations of a critical We want to do all the operations of a critical

section as a single logical ‘unit’ of worksection as a single logical ‘unit’ of work– it is either done completely or not at allit is either done completely or not at all

A transaction can be viewed as a sequence of A transaction can be viewed as a sequence of readreads and s and writewrites on shared data, ending with s on shared data, ending with a a commitcommit or or abortabort operation operation

An An abortabort causes a partial transaction to be causes a partial transaction to be rolled backrolled back

OSes: 5. Synch 79

10.1. Log-based Recovery10.1. Log-based Recovery

Atomicity is ensured by logging transaction Atomicity is ensured by logging transaction operations to stable storageoperations to stable storage– these can be replayed or used for rollback if these can be replayed or used for rollback if

failure occursfailure occurs

Log details:Log details:– transaction name, data name, old value,transaction name, data name, old value,

new valuenew value

continued

OSes: 5. Synch 80

Write-ahead logging:Write-ahead logging:– log a write operation log a write operation beforebefore doing it doing it

– log the transaction start and its commitlog the transaction start and its commit

OSes: 5. Synch 81

ExampleExample

begin transaction read X if (X >= a) then {

read Y X = X - a Y = Y + a write X write Y }end transaction

<Ti, start><Ti, start>

<Ti, X, oldV, newV><Ti, X, oldV, newV><Ti, Y, oldV, newV><Ti, Y, oldV, newV>

<Ti, commit><Ti, commit>

(VUW CS 305)

OSes: 5. Synch 82

RecoveryRecovery

Operations:Operations:– undo( Transactionundo( Transactioni i ))

– redo( Transactionredo( Transactioni i ))

Possible states of Possible states of TransactionTransactionii

– committed, but were new values written?committed, but were new values written?– aborted, but were old values restored?aborted, but were old values restored?– unfinishedunfinished

OSes: 5. Synch 83

10.2. Checkpoints10.2. Checkpoints

A checkpoint fixes state changes by writing A checkpoint fixes state changes by writing them to stable storage so that the log file them to stable storage so that the log file can be reset or shortened.can be reset or shortened.

OSes: 5. Synch 84

10.3. Concurrent Atomic Transactions10.3. Concurrent Atomic Transactions

We want to ensure that the outcome of We want to ensure that the outcome of concurrent transactions are the same as if concurrent transactions are the same as if they were executed in some serial orderthey were executed in some serial order– serializabilityserializability

OSes: 5. Synch 85

A Serial ScheduleA Serial Schedule

Transaction 0Transaction 0 Transaction 1Transaction 1

read Aread Awrite Awrite Aread Bread Bwrite Bwrite B

read A read A write A write A read B read B write B write B

Fig. 6.23, p.195

OSes: 5. Synch 86

Conflicting OperationsConflicting Operations

Two operations in different transactions Two operations in different transactions conflict if they access the same data and conflict if they access the same data and one of them is a one of them is a writewrite..

Serializability must avoid conflicting Serializability must avoid conflicting operations:operations:– it can do that by delaying/speeding up when it can do that by delaying/speeding up when

operations in a transaction are performedoperations in a transaction are performed

OSes: 5. Synch 87

A Concurrent Serializable ScheduleA Concurrent Serializable Schedule

Transaction 0Transaction 0 Transaction 1Transaction 1

read Aread Awrite Awrite A

read A read A write A write A

read Bread Bwrite Bwrite B

read B read B write B write B

Fig. 6.24, p.196

OSes: 5. Synch 88

10.4. Locks10.4. Locks

Serializability can be achieved by locking Serializability can be achieved by locking data itemsdata items

There are a range of locking modes:There are a range of locking modes:– a a shared lockshared lock allows multiple reads by allows multiple reads by

different transactionsdifferent transactions– an an exclusive lockexclusive lock allows only one transaction allows only one transaction

to do reads/writesto do reads/writes

OSes: 5. Synch 89

10.5. Timestamping10.5. Timestamping

One way of ordering transactionsOne way of ordering transactions

Using the system clock is not sufficient Using the system clock is not sufficient when transactions may originate on when transactions may originate on different machinesdifferent machines