Chapter 6: Process Synchronization

Chapter 6: Chapter 6: Process Process

SynchronizationSynchronization

22

Module 6: Process Module 6: Process SynchronizationSynchronization

BackgroundBackgroundThe Critical-Section ProblemThe Critical-Section ProblemPeterson’s SolutionPeterson’s SolutionSynchronization HardwareSynchronization HardwareSemaphoresSemaphoresClassic Problems of SynchronizationClassic Problems of SynchronizationMonitorsMonitorsSynchronization Examples Synchronization Examples Atomic TransactionsAtomic Transactions

33

ObjectivesObjectives

To introduce the To introduce the critical-section problemcritical-section problem, , whose solutions can be used to ensure the whose solutions can be used to ensure the consistency of shared dataconsistency of shared data

To present both software and hardware To present both software and hardware solutions of the critical-section problemsolutions of the critical-section problem

To introduce the concept of an To introduce the concept of an atomic atomic transactiontransaction and describe mechanisms to and describe mechanisms to ensure atomicityensure atomicity

44

BackgroundBackground

Concurrent access to shared data may result in Concurrent access to shared data may result in data inconsistencydata inconsistency

Maintaining data consistency requires Maintaining data consistency requires mechanisms to ensure the orderly execution of mechanisms to ensure the orderly execution of cooperating processescooperating processes

Suppose that we wanted to provide a solution Suppose that we wanted to provide a solution to the consumer-producer problem that fills to the consumer-producer problem that fills all all the buffers. the buffers.

55

We can do so by having an integer We can do so by having an integer countcount that keeps track of the number of full that keeps track of the number of full buffers. buffers.

Initially, count is set to 0. It is incremented Initially, count is set to 0. It is incremented by the producer after it produces a new by the producer after it produces a new buffer and is decremented by the buffer and is decremented by the consumer after it consumes a buffer.consumer after it consumes a buffer.

66



77

Producer Producer

while (true) {while (true) {

/* produce an item and put in /* produce an item and put in nextProduced */nextProduced */

while (count == BUFFER_SIZE) ; while (count == BUFFER_SIZE) ;

// do nothing// do nothing

buffer [in] = nextProduced;buffer [in] = nextProduced;

in = (in + 1) % BUFFER_SIZE;in = (in + 1) % BUFFER_SIZE;

count++;count++;

} }

88

ConsumerConsumer while (true) {while (true) {

while (count == 0); while (count == 0);

// do nothing// do nothing

nextConsumed = buffer[out];nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;out = (out + 1) % BUFFER_SIZE;

count--;count--;

// consume the item in // consume the item in nextConsumednextConsumed

}}

99

Race ConditionsRace Conditionscount++count++ could be implemented as could be implemented as register1 = countregister1 = count register1 = register1 + 1 register1 = register1 + 1 count = register1 count = register1

count--count-- could be implemented as could be implemented as register2 = countregister2 = count register2 = register2 - 1 register2 = register2 - 1 count = register2 count = register2

1010

Consider this execution interleaving with “count = 5” Consider this execution interleaving with “count = 5” initially:initially:

S0: producer execute S0: producer execute register1 = countregister1 = count {register1 {register1 = 5}= 5}S1: producer execute S1: producer execute register1 = register1 + 1register1 = register1 + 1 {register1 = 6} {register1 = 6} S2: consumer execute S2: consumer execute register2 = countregister2 = count {register2 {register2 = 5} = 5} S3: consumer execute S3: consumer execute register2 = register2 - 1register2 = register2 - 1 {register2 = 4} {register2 = 4} S4: producer execute S4: producer execute count = register1count = register1 {count = {count = 6 } 6 } S5: consumer execute S5: consumer execute count = register2count = register2 {count = {count = 4}4}

1111

Requirements for a Solution to Requirements for a Solution to the Critical-Section Problemthe Critical-Section Problem

1.1. Mutual ExclusionMutual Exclusion - If process - If process PPii is executing in its is executing in its

critical section, then no other processes can be critical section, then no other processes can be executing in their critical sectionsexecuting in their critical sections

2.2. ProgressProgress - If no process is executing in its critical - If no process is executing in its critical section and there exist some processes that wish to section and there exist some processes that wish to enter their critical section, then the selection of the enter their critical section, then the selection of the processes that will enter the critical section next processes that will enter the critical section next cannot be postponed indefinitelycannot be postponed indefinitely

1212

Requirements for a Solution to Requirements for a Solution to the Critical-Section Problemthe Critical-Section Problem

3.3. Bounded WaitingBounded Waiting - A bound must exist on the - A bound must exist on the number of times that other processes are number of times that other processes are allowed to enter their critical sections after a allowed to enter their critical sections after a process has made a request to enter its critical process has made a request to enter its critical section and before that request is grantedsection and before that request is grantedAssume that each process executes at a Assume that each process executes at a

nonzero speed nonzero speed No assumption concerning relative speed of No assumption concerning relative speed of

the the NN processes processes

1313



1414

Peterson’s SolutionPeterson’s SolutionA two process solutionA two process solutionAssume that the LOAD and STORE instructions Assume that the LOAD and STORE instructions are atomic; that is, they cannot be interrupted.are atomic; that is, they cannot be interrupted.The two processes share two variables:The two processes share two variables: intint turnturn; ; Boolean Boolean flag[2]flag[2]

The variable The variable turnturn indicates whose turn it is to indicates whose turn it is to enter the critical section. enter the critical section. The The flagflag array is used to indicate if a process is array is used to indicate if a process is ready to enter the critical section. ready to enter the critical section. flag[i]flag[i] = true = true implies that process implies that process PPii is ready!is ready!

1515

do { do {

flag[ i ] = TRUE; flag[ i ] = TRUE;

turn = j; turn = j;

while (flag[ j ] && turn == j); while (flag[ j ] && turn == j);

critical section critical section

flag[ i ] = FALSE; flag[ i ] = FALSE;

remainder section remainder section

} while (TRUE); } while (TRUE);

Algorithm for Process Algorithm for Process PPii

1616

do { //P0do { //P0flag[ 0 ] = TRUE; flag[ 0 ] = TRUE; turn = 1; turn = 1; while (flag[ 1 ] && while (flag[ 1 ] &&

turn == 1); turn == 1); critical section critical section flag[ 0 ] = FALSE; flag[ 0 ] = FALSE;

remainder section remainder section } while (TRUE); } while (TRUE);

do { //P1do { //P1flag[ 1 ] = TRUE; flag[ 1 ] = TRUE; turn = 0; turn = 0; while (flag[ 0 ] && while (flag[ 0 ] &&

turn == 0); turn == 0); critical section critical section flag[ 1] = FALSE; flag[ 1] = FALSE;

remainder section remainder section } while (TRUE); } while (TRUE);

1717



1818

Synchronization HardwareSynchronization HardwareMany systems provide hardware support for critical Many systems provide hardware support for critical section codesection codeUniprocessors – could disable interruptsUniprocessors – could disable interrupts Currently running code would execute without Currently running code would execute without

preemptionpreemption Generally too inefficient on multiprocessor systemsGenerally too inefficient on multiprocessor systems

Operating systems using this not broadly scalableOperating systems using this not broadly scalableModern machines provide special atomic hardware Modern machines provide special atomic hardware instructionsinstructions

Atomic = non-interruptableAtomic = non-interruptable Either test memory word and set valueEither test memory word and set value Or swap contents of two memory wordsOr swap contents of two memory words

1919

Solution to Critical-section Problem Solution to Critical-section Problem Using LocksUsing Locks

do { do {

acquire lock acquire lock

critical section critical section

release lock release lock

remainder section remainder section

} while (TRUE); } while (TRUE);

2020

TestAndndSet Instruction TestAndndSet Instruction

Definition:Definition:

boolean TestAndSet (boolean *target)boolean TestAndSet (boolean *target) {{ boolean rv = *target;boolean rv = *target; *target = TRUE;*target = TRUE; return rv:return rv: }}

2121

Solution Using TestAndSetSolution Using TestAndSet

Shared boolean variable lock., initialized to false.Shared boolean variable lock., initialized to false.Solution:Solution:

do {do { while ( TestAndSet (&lock ))while ( TestAndSet (&lock )) ; // do nothing; // do nothing // critical section// critical section lock = FALSE;lock = FALSE; // remainder section // remainder section } while (TRUE);} while (TRUE);

2222

boolean TestAndSet (boolean *target)boolean TestAndSet (boolean *target) {{ boolean rv = *target;boolean rv = *target; *target = TRUE;*target = TRUE; return rv:return rv: }}do {do {

while ( TestAndSet while ( TestAndSet (&lock )) ; (&lock )) ; // do // do nothingnothing // critical section// critical section lock = FALSE;lock = FALSE; // remainder section // remainder section } while (TRUE);} while (TRUE);

do {do { while ( TestAndSetwhile ( TestAndSet

(&lock ));(&lock )); // do nothing// do nothing // critical section// critical section lock = FALSE;lock = FALSE; // remainder section // remainder section } while (TRUE);} while (TRUE);

Both start with lock = false.

2323

Bounded-waiting Mutual Exclusion with TestandSet() Bounded-waiting Mutual Exclusion with TestandSet() for Pi processfor Pi process

do { waiting[ i ] = TRUE; do { waiting[ i ] = TRUE;

key = TRUE; key = TRUE;

while (waiting[i] && key) while (waiting[i] && key)

key = TestAndSet(&lock); key = TestAndSet(&lock);

waiting[i] = FALSE; waiting[i] = FALSE;

// critical section // critical section

j = (i + 1) % n; j = (i + 1) % n;

while (( j != i) && !waiting[ j ] ) while (( j != i) && !waiting[ j ] )

j = (j + 1) % n; j = (j + 1) % n;

if (j == i) if (j == i)

lock = FALSE; lock = FALSE;

elseelse waiting [ j ] = FALSE; waiting [ j ] = FALSE;

// remainder section // remainder section

} while (TRUE);} while (TRUE);

Waiting and Lock are initially set to false.

2424

do { waiting[ i ] = TRUE; do { waiting[ i ] = TRUE; key = TRUE; key = TRUE; while (waiting[i] && key) while (waiting[i] && key)

key = TestAndSet(&lock); key = TestAndSet(&lock); waiting[i] = FALSE; waiting[i] = FALSE; // critical section // critical section j = (i + 1) % n; j = (i + 1) % n; while (( j != i) && !waiting[ j ] ) while (( j != i) && !waiting[ j ] ) j = (j + 1) % n; j = (j + 1) % n; if (j == i) if (j == i) lock = FALSE; lock = FALSE; elseelse waiting [ j ] = FALSE; waiting [ j ] = FALSE; // remainder section // remainder section


do { waiting[ k ] = TRUE; do { waiting[ k ] = TRUE; key = TRUE; key = TRUE; while (waiting[k] && key) while (waiting[k] && key)

key = TestAndSet(&lock); key = TestAndSet(&lock); waiting[k] = FALSE; waiting[k] = FALSE; // critical section // critical section m = (k + 1) % n; m = (k + 1) % n; while (( m != k) && !waiting[ m ] ) while (( m != k) && !waiting[ m ] ) m= (m + 1) % n; m= (m + 1) % n; if (m == k if (m == k

lock = FALSE; lock = FALSE; elseelse waiting [ m ] = FALSE; waiting [ m ] = FALSE; // remainder section // remainder section


2525

Swap InstructionSwap Instruction

Definition:Definition:

void Swap (boolean *a, boolean *b)void Swap (boolean *a, boolean *b) {{ boolean temp = *a;boolean temp = *a; *a = *b;*a = *b; *b = temp:*b = temp: }}

2626

Solution Using SwapSolution Using SwapShared Boolean variable lock initialized to FALSE; Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable keyEach process has a local Boolean variable keySolution:Solution:

do { key = TRUE;do { key = TRUE; while ( key == TRUE)while ( key == TRUE) Swap (&lock, &key );Swap (&lock, &key ); // critical section// critical section lock = FALSE;lock = FALSE; // remainder section // remainder section } while (TRUE);} while (TRUE);

2727



2828

SemaphoreSemaphore

We need a synchronization tool that does not require We need a synchronization tool that does not require busy waiting busy waiting Semaphore Semaphore SS – integer variable – integer variableTwo standard operations modify Two standard operations modify S: wait()S: wait() and and signal()signal() Originally called Originally called P()P() andand V()V()Less complicatedLess complicatedOur first approach does use a busy waiting, but Our first approach does use a busy waiting, but because the code is short and easy to understand, it because the code is short and easy to understand, it is less prone to implementation problems.is less prone to implementation problems.But, as we will see, there are times it should not be But, as we will see, there are times it should not be used,used,

• P and V come from the initials of Dutch words. • V stands for verhogen, or "increase".• Several explanations have been given for P , but

Dijkstra wrote that he intended P to stand for the made-up word prol short for probeer te verlagen, or "try-and-decrease" .

• A less ambiguous, and more accurate, English translation would be "try-to-decrease".

• This confusion stems from the fact that the words for increase and decrease both begin with the letter V in Dutch, and the words spelled out in full would be impossibly confusing for non–Dutch-speakers.

3030

Can only be accessed via two indivisible Can only be accessed via two indivisible (atomic) operations(atomic) operations wait (S) { wait (S) {

while S <= 0 ; // no-opwhile S <= 0 ; // no-op

S--;S--;

}} signal (S) { signal (S) {

S++;S++;

}}

3131

Semaphore as General Semaphore as General Synchronization ToolSynchronization Tool

Counting semaphoreCounting semaphore – integer value can range over – integer value can range over an unrestricted domainan unrestricted domain

Binary semaphoreBinary semaphore – integer value can range only – integer value can range only between 0 and 1; can be simpler to implementbetween 0 and 1; can be simpler to implement Also known as Also known as mutex locksmutex locks

Can implement a counting semaphore Can implement a counting semaphore S S as a binary as a binary semaphoresemaphore

3232

Provides mutual exclusionProvides mutual exclusionSemaphore mutex; // initialized to 1Semaphore mutex; // initialized to 1

do {do {

wait (mutex);wait (mutex);

// Critical Section// Critical Section

signal (mutex);signal (mutex);

// remainder section// remainder section


3333

Semaphore ImplementationSemaphore Implementation

Must guarantee that no two processes can Must guarantee that no two processes can execute execute wait ()wait () and and signal ()signal () on the same on the same semaphore at the same timesemaphore at the same time

Thus, implementation becomes the critical Thus, implementation becomes the critical section problem where the wait and signal code section problem where the wait and signal code are placed in the critical section.are placed in the critical section.

3434

Could now have Could now have busy waitingbusy waiting in critical in critical section implementationsection implementation

But implementation code is shortBut implementation code is short

There is little busy waiting if critical section There is little busy waiting if critical section is rarely occupiedis rarely occupied

Note that applications may spend lots of time in Note that applications may spend lots of time in critical sections and therefore this is not a good critical sections and therefore this is not a good solutionsolution..

3535

Semaphore Implementation with No Semaphore Implementation with No Busy WaitingBusy Waiting

With each semaphore there is an associated waiting With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data queue. Each entry in a waiting queue has two data items:items: value (of type integer)value (of type integer) pointer to next record in the listpointer to next record in the list

3636

Semaphore Implementation with Semaphore Implementation with No Busy WaitingNo Busy Waiting

Two operations:Two operations: blockblock – place the process invoking the – place the process invoking the

operation on the appropriate waiting queue.operation on the appropriate waiting queue. wakeup wakeup – remove one of processes in the – remove one of processes in the

waiting queue and place it in the ready queue.waiting queue and place it in the ready queue.

3737

Semaphore Implementation with no Semaphore Implementation with no Busy waitingBusy waiting (Cont.)(Cont.)

Implementation of wait:Implementation of wait: wait(semaphore *S) { wait(semaphore *S) {

S->value--; S->value--; if (S->value < 0) { if (S->value < 0) {

add this process to S-add this process to S->list; >list;

block(); //this processblock(); //this process} }

}}

3838

Semaphore Implementation with no Semaphore Implementation with no Busy waitingBusy waiting (Cont.)(Cont.)

Implementation of signal:Implementation of signal:

signal(semaphore *S) { signal(semaphore *S) {

S->value++; S->value++;

if (S->value <= 0) { if (S->value <= 0) {

remove a process P from S->list; remove a process P from S->list;

wakeup(P); wakeup(P);

}}

} }

3939

Deadlock and StarvationDeadlock and StarvationDeadlockDeadlock – two or more processes are waiting – two or more processes are waiting indefinitely for an event that can be caused by only indefinitely for an event that can be caused by only one of the waiting processesone of the waiting processesLet Let SS and and QQ be two semaphores initialized to 1 be two semaphores initialized to 1

PP00 PP11

wait (S); wait (S); wait (Q); wait (Q); wait (Q); wait (Q); wait (S); wait (S);

. . .. . . . . .. . . .. signal (S); signal (S); signal (Q); signal (Q); signal (Q); signal (Q); signal (S); signal (S);

4040

StarvationStarvation – indefinite blocking. A process may – indefinite blocking. A process may never be removed from the semaphore queue in never be removed from the semaphore queue in which it is suspendedwhich it is suspended

Priority InversionPriority Inversion - Scheduling problem when - Scheduling problem when lower-priority process holds a lock needed by lower-priority process holds a lock needed by higher-priority processhigher-priority process

4141



4242

Classical Problems of Classical Problems of SynchronizationSynchronization

Bounded-Buffer ProblemBounded-Buffer Problem

Readers and Writers ProblemReaders and Writers Problem

Dining-Philosophers ProblemDining-Philosophers Problem

4343

Bounded-Buffer ProblemBounded-Buffer Problem

NN buffers, each can hold one item buffers, each can hold one item

Semaphore Semaphore mutexmutex initialized to the initialized to the value 1value 1

Semaphore Semaphore full full initialized to the initialized to the value 0value 0

Semaphore Semaphore emptyempty initialized to the initialized to the value N.value N.

4444

Semaphore Implementation with no Semaphore Implementation with no Busy waiting - repeat slide for referenceBusy waiting - repeat slide for reference

Implementation of wait:Implementation of wait: wait(semaphore *S) { wait(semaphore *S) {

S->value--; S->value--; if (S->value < 0) { if (S->value < 0) {

add this process to S-add this process to S->list; >list;

block(); //this processblock(); //this process} }

}}

4545

Semaphore Implementation with no Semaphore Implementation with no Busy waiting- Busy waiting- repeat slide for repeat slide for

referencereferenceImplementation of signal:Implementation of signal:

signal(semaphore *S) { signal(semaphore *S) {

S->value++; S->value++;

if (S->value <= 0) { if (S->value <= 0) {

remove a process P from S->list; remove a process P from S->list;

wakeup(P); wakeup(P);

}}

} }

4646

Bounded Buffer Problem (Cont.)Bounded Buffer Problem (Cont.)The structure of the producer processThe structure of the producer process

do { // produce an item in nextpdo { // produce an item in nextp

wait (empty);wait (empty);


// add the item to the buffer// add the item to the buffer


signal (full);signal (full);


4747

Bounded Buffer Problem (Cont.)Bounded Buffer Problem (Cont.)

The structure of the consumer processThe structure of the consumer process

do { wait (full);do { wait (full);


// remove an item from buffer to nextc// remove an item from buffer to nextc


signal (empty);signal (empty);

// consume the item in nextc// consume the item in nextc


4848

Readers-Writers ProblemReaders-Writers ProblemA data set is shared among a number of concurrent A data set is shared among a number of concurrent processesprocesses Readers – only read the data set; they do Readers – only read the data set; they do not not perform any perform any

updatesupdates Writers – can both read and writeWriters – can both read and write

Problem – allow multiple readers to read at the same time. Problem – allow multiple readers to read at the same time. Only one single writer can access the shared data at the Only one single writer can access the shared data at the same timesame time

Shared DataShared Data Data setData set Semaphore Semaphore mutexmutex initialized to 1 initialized to 1 Semaphore Semaphore wrtwrt initialized to 1 initialized to 1 Integer Integer readcountreadcount initialized to 0 initialized to 0

4949

Readers-Writers Problem Readers-Writers Problem (Cont.)(Cont.)

The structure of a writer processThe structure of a writer process

wrt initialized to 1wrt initialized to 1

do {do {

wait (wrt) ;wait (wrt) ;

// writing is performed// writing is performed

signal (wrt) ;signal (wrt) ;


5050

Readers-Writers Problem (Cont.Readers-Writers Problem (Cont.mutex and wrt start at 1; readcount to 0.mutex and wrt start at 1; readcount to 0.The structure of a reader processThe structure of a reader process

do { wait (mutex) ;do { wait (mutex) ; readcount ++ ;readcount ++ ; if (readcount == 1) wait (wrt) ;if (readcount == 1) wait (wrt) ; signal (mutex)signal (mutex) // reading is performed// reading is performed wait (mutex) ;wait (mutex) ; readcount - - ;readcount - - ; if (readcount == 0) signal (wrt) ;if (readcount == 0) signal (wrt) ; signal (mutex) ;signal (mutex) ; } while (TRUE);} while (TRUE);

5151

Dining-Philosophers' ProblemDining-Philosophers' Problem

Shared data Shared data Bowl of rice (data set)Bowl of rice (data set) Semaphore Semaphore chopstick [5]chopstick [5] initialized to 1 initialized to 1

5252

Dining-Philosophers' Problem (Cont.)Dining-Philosophers' Problem (Cont.)

The structure of PhilosopherThe structure of Philosopher do { do { wait ( chopstick[i] );wait ( chopstick[i] );

wait ( chopStick[ (i + 1) % 5] );wait ( chopStick[ (i + 1) % 5] ); // eat// eat signal ( chopstick[i] );signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] );signal (chopstick[ (i + 1) % 5] );

// think// think} while (TRUE);} while (TRUE);

5353

Problems with SemaphoresProblems with Semaphores Correct use of semaphore operations:Correct use of semaphore operations:

signal (mutex) …. wait (mutex)signal (mutex) …. wait (mutex)

wait (mutex) … wait (mutex)wait (mutex) … wait (mutex)

Omitting of wait (mutex) or signal Omitting of wait (mutex) or signal (mutex) (or both)(mutex) (or both)

5454



5555

MonitorsMonitorsA high-level abstraction that provides a convenient and A high-level abstraction that provides a convenient and effective mechanism for process synchronizationeffective mechanism for process synchronizationOnly one process may be active within the monitor at a Only one process may be active within the monitor at a timetime

monitor monitor-namemonitor monitor-name{ // shared variable declarations{ // shared variable declarations

procedure P1 (…) { …. }procedure P1 (…) { …. }……

procedure Pn (…) {……}procedure Pn (…) {……} Initialization code ( ….) { … }Initialization code ( ….) { … }

……}}

}}

5656

Schematic View of a MonitorSchematic View of a Monitor

5757

Condition VariablesCondition Variables

condition x, y;condition x, y;

Two operations on a condition variable:Two operations on a condition variable: x.wait ()x.wait () – – suspendssuspends the process that invokes the the process that invokes the

operation. operation. x.signal ()x.signal () –– resumesresumes one of processes one of processes (if any)(if any) thatthat

invokedinvoked x.wait ()x.wait ()

5858

Monitor with Condition Monitor with Condition VariablesVariables

Monitors as ADT

Like a class - ecapsulates private data wth public methods that operate on the data.

The monitor type contains the declaration of variables whose values define the state of an instance of that type, along with the bodies of procedures or functions that operate on the variables.

A monitor representation can't be used directly by the various processes.

A procedure defined within a monitor can access only those variables declared locally within the monitor and its formal parameters.

Local variables of a monitor can be accessed only by the local procedures.

Important fact: The monitor construction must ensure that only one process at a time is active within the monitor.

Monitors were developed by C.A.R. Hoare (1974) and Per Brinch Hansen (1975)

Kind of like an abstract data type, or a C++ class, with synchronization built in

Biases the way you write code — also one of the original ideas No C++ in those days!

Enforces mutual exclusion in the monitor

The programmer doesn’t code anything having to do with locks This is safer, because it eliminates a source

of programmer error

Concurrent Pascal, Pascal-plus, Modula-2, Modula-3 Not many people used such languages

6363

Solution to Dining PhilosophersSolution to Dining Philosophersmonitor DPmonitor DP { enum { THINKING; HUNGRY, EATING} state [5] ;{ enum { THINKING; HUNGRY, EATING} state [5] ;

condition self [5];condition self [5];void pickup (int i) { void pickup (int i) { state[i] = HUNGRY;state[i] = HUNGRY; test(i);test(i); if (state[i] != EATING) self [i].wait;if (state[i] != EATING) self [i].wait;}}

void putdown (int i) { void putdown (int i) { state[i] = THINKING;state[i] = THINKING;

// test left and right neighbors// test left and right neighbors test((i + 4) % 5);test((i + 4) % 5); test((i + 1) % 5);test((i + 1) % 5);

}}==>

6464

Solution to Dining Philosophers Solution to Dining Philosophers

void test (int i) { void test (int i) { if ( (state[(i + 4) % 5] != EATING) &&if ( (state[(i + 4) % 5] != EATING) && (state[ i ] == HUNGRY) &&(state[ i ] == HUNGRY) && (state[( i + 1) % 5] != EATING) ) { (state[( i + 1) % 5] != EATING) ) { state[ i ] = EATING ;state[ i ] = EATING ;

self [ i ].signal () ;self [ i ].signal () ; }} }}

initialization_code() { initialization_code() { for (int i = 0; i < 5; i++)for (int i = 0; i < 5; i++) state[i] = THINKING;state[i] = THINKING;}}

}}

Each philosopher i calls pickup(i), eats, calls putdown(i)

Functions test puts philosopher(I) in the eating state if possible and sends it a signal If the test was not successful pickup ends up

waiting If the test was successful it goes into eating

state and the signal just gets ignored

When the eater puts down his fork he puts his neighbors into the eating state if possible and sends successful eaters a signal (which they may be waiting for)

Mutual exclusion — satisfied

Deadlock — satisfied

However, a philosopher can starve! Philosophers 1 and 3 both need 2’s fork If 1 finishes and puts down fork 2, 2 cannot

eat until 3 also finishes However, if 1 tries to eat again before 3

finishes, he grabs fork 2 again, and starts eating

Then 3 can do the same thing, and 2 can starve

6868

Solution to Dining Philosophers Solution to Dining Philosophers (cont)(cont)

Each philosopher Each philosopher I I invokes theinvokes the operations operations pickup() pickup() and and putdown()putdown() in the following in the following sequence:sequence:

DiningPhilosophters.pickup (i);DiningPhilosophters.pickup (i); EATEAT DiningPhilosophers.putdown (i);DiningPhilosophers.putdown (i);

6969

Monitor Implementation Using SemaphoresMonitor Implementation Using SemaphoresVariables Variables

semaphore mutex; // (initially = 1)semaphore mutex; // (initially = 1)semaphore next; // (initially = 0)semaphore next; // (initially = 0)int next-count = 0;int next-count = 0;

Each procedure Each procedure FF will be replaced by will be replaced bywait(mutex);wait(mutex); … … body of body of FF;; … …if (next_count > 0)if (next_count > 0) signal(next)signal(next)

else else signal(mutex);signal(mutex);

Mutual exclusion within a monitor is ensured.Mutual exclusion within a monitor is ensured.

7070

Monitor ImplementationMonitor ImplementationFor each condition variable For each condition variable xx, we have:, we have:

semaphore x_sem; // (initially = 0)semaphore x_sem; // (initially = 0)int x-count = 0;int x-count = 0;

The operation The operation x.waitx.wait can be implemented as:can be implemented as:x-count++;x-count++;if (next_count > 0)if (next_count > 0)

signal(next);signal(next);elseelse

signal(mutex);signal(mutex);wait(x_sem);wait(x_sem);x-count--;x-count--;

7171

Monitor ImplementationMonitor ImplementationThe operation The operation x.signal x.signal can be implemented as:can be implemented as:

if (x-count > 0) {if (x-count > 0) {

next_count++;next_count++;

signal(x_sem);signal(x_sem);

wait(next);wait(next);

next_count--;next_count--;

}}

7272

A Monitor to Allocate Single A Monitor to Allocate Single ResourceResource

monitor ResourceAllocator monitor ResourceAllocator

{ boolean busy; { boolean busy;

condition x; condition x;

void acquire(int time) { initialization code() {void acquire(int time) { initialization code() {

if (busy) busy = FALSE; }if (busy) busy = FALSE; }

x.wait(time); }x.wait(time); }

busy = TRUE; } busy = TRUE; }

void release() { void release() {

busy = FALSE; busy = FALSE;

x.signal(); } x.signal(); }

7373



7474

Synchronization ExamplesSynchronization Examples

SolarisSolaris

Windows XPWindows XP

LinuxLinux

PthreadsPthreads

7575

Solaris SynchronizationSolaris SynchronizationImplements a variety of locks to support Implements a variety of locks to support multitasking, multithreading (including real-multitasking, multithreading (including real-time threads), and multiprocessingtime threads), and multiprocessing

Uses Uses adaptive mutexesadaptive mutexes for efficiency when for efficiency when protecting data from short code segmentsprotecting data from short code segments

Uses Uses condition variablescondition variables and and readers-readers-writerswriters locks when longer sections of code locks when longer sections of code need access to dataneed access to data

Uses Uses turnstiles turnstiles to order the list of threads to order the list of threads waiting to acquire either an adaptive waiting to acquire either an adaptive mutex or reader-writer lockmutex or reader-writer lock

7676

Windows XP SynchronizationWindows XP Synchronization

Uses interrupt masks to protect access to Uses interrupt masks to protect access to global resources on uniprocessor systemsglobal resources on uniprocessor systems

Uses Uses spinlocksspinlocks on multiprocessor systemson multiprocessor systems

Also provides Also provides dispatcher objectsdispatcher objects which may which may act as either mutexes and semaphoresact as either mutexes and semaphores

Dispatcher objects may also provide Dispatcher objects may also provide eventsevents An event acts much like a condition variableAn event acts much like a condition variable

7777

Linux SynchronizationLinux SynchronizationLinux:Linux: Prior to kernel Version 2.6, disables interrupts Prior to kernel Version 2.6, disables interrupts

to implement short critical sectionsto implement short critical sections Version 2.6 and later, fully preemptiveVersion 2.6 and later, fully preemptive

Linux provides:Linux provides: semaphoressemaphores spin locksspin locks

7878

Pthreads SynchronizationPthreads Synchronization

Pthreads API is OS independentPthreads API is OS independent

It provides:It provides: mutex locksmutex locks condition variablescondition variables

Non-portable extensions include:Non-portable extensions include: read-write locksread-write locks spin locksspin locks

7979



8080

Atomic TransactionsAtomic Transactions

System ModelSystem Model

Log-based RecoveryLog-based Recovery

CheckpointsCheckpoints

Concurrent Atomic TransactionsConcurrent Atomic Transactions

8181


Assures that operations happen as a single Assures that operations happen as a single logical unit of work, in its entirety, or not at alllogical unit of work, in its entirety, or not at all

Related to field of database systemsRelated to field of database systems

Challenge is assuring atomicity despite Challenge is assuring atomicity despite computer system failurescomputer system failures

8282


TransactionTransaction - collection of instructions or - collection of instructions or operations that performs single logical functionoperations that performs single logical function Here we are concerned with changes to stable Here we are concerned with changes to stable

storage – diskstorage – disk Transaction is series of Transaction is series of readread and and writewrite operations operations Terminated by Terminated by commit commit (transaction successful) or (transaction successful) or

abort abort (transaction failed) operation(transaction failed) operation Aborted transaction must be Aborted transaction must be rolled backrolled back to undo to undo

any changes it performedany changes it performed

8383

Types of Storage MediaTypes of Storage MediaVolatile storage – information stored here does not survive system Volatile storage – information stored here does not survive system crashescrashes Example: main memory, cacheExample: main memory, cache

Nonvolatile storage – Information usually survives crashesNonvolatile storage – Information usually survives crashes Example: disk and tapeExample: disk and tape

Stable storage – Information never lostStable storage – Information never lost Not actually possible, so approximated via replication or RAID to Not actually possible, so approximated via replication or RAID to

devices with independent failure modesdevices with independent failure modes

Goal is to assure transaction atomicity where failures cause loss of information on volatile storage

8484

Log-Based RecoveryLog-Based RecoveryRecord to stable storage information about all modifications by Record to stable storage information about all modifications by a transactiona transaction

Most common is Most common is write-ahead loggingwrite-ahead logging Log on stable storage, each log record describes single Log on stable storage, each log record describes single

transaction write operation, includingtransaction write operation, including

Transaction nameTransaction name

Data item nameData item name

Old valueOld value

New valueNew value <T<Tii starts> written to log when transaction T starts> written to log when transaction Tii starts starts

<T<Ti i commits> written when Tcommits> written when Tii commits commits

Log entry must reach stable storage before operation on data Log entry must reach stable storage before operation on data occursoccurs

8585

Log-Based Recovery AlgorithmLog-Based Recovery Algorithm

Using the log, system can handle any volatile Using the log, system can handle any volatile memory errorsmemory errors Undo(TUndo(Tii)) restores value of all data updated by T restores value of all data updated by T ii

Redo(TRedo(Tii)) sets values of all data in transaction T sets values of all data in transaction T ii to to

new valuesnew values

Undo(TUndo(Tii) and redo(T) and redo(Tii) must be ) must be idempotentidempotent Multiple executions must have the same result as Multiple executions must have the same result as

one executionone execution

8686

If system fails, restore state of all updated If system fails, restore state of all updated data via logdata via log If log contains <TIf log contains <T ii starts> without <T starts> without <T ii

commits>, commits>, undo(Tundo(Tii))

If log contains <TIf log contains <T ii starts> and <T starts> and <Tii commits>, commits>,

redo(Tredo(Tii))

8787

CheckpointsCheckpoints

A log could become long, and recovery could A log could become long, and recovery could take a long timetake a long time

Checkpoints shorten log and recovery time.Checkpoints shorten log and recovery time.

Checkpoint scheme:Checkpoint scheme:1.1. Output all log records currently in volatile storage to Output all log records currently in volatile storage to

stable storagestable storage

2.2. Output all modified data from volatile to stable Output all modified data from volatile to stable storagestorage

3.3. Output a log record <checkpoint> to the log on Output a log record <checkpoint> to the log on stable storagestable storage

8888

Now recovery only includes Ti, such that Now recovery only includes Ti, such that Ti started executing before the most Ti started executing before the most recent checkpoint, and all transactions recent checkpoint, and all transactions after Ti All other transactions already on after Ti All other transactions already on stable storagestable storage

8989

Concurrent TransactionsConcurrent TransactionsMust be equivalent to serial execution – Must be equivalent to serial execution – serializabilityserializability

Could perform all transactions in critical sectionCould perform all transactions in critical section Inefficient, too restrictiveInefficient, too restrictive

Concurrency-control algorithmsConcurrency-control algorithms provide provide serializabilityserializability

9090

SerializabilitySerializability

Consider two data items A and BConsider two data items A and B

Consider Transactions TConsider Transactions T0 0 and Tand T11

Execute TExecute T00, T, T11 atomically atomically

Execution sequence called Execution sequence called scheduleschedule

Atomically executed transaction order Atomically executed transaction order called called serial scheduleserial schedule

For N transactions, there are N! valid For N transactions, there are N! valid serial schedulesserial schedules

9191

Schedule 1: TSchedule 1: T00 then T then T11

9292

Nonserial ScheduleNonserial ScheduleNonserial scheduleNonserial schedule allows overlapped executeallows overlapped execute Resulting execution not necessarily incorrectResulting execution not necessarily incorrect

Consider schedule S, operations OConsider schedule S, operations O ii, O, Ojj

ConflictConflict if access same data item, with at least one write if access same data item, with at least one write

If OIf Oii, O, Ojj consecutive and operations of different consecutive and operations of different

transactions & Otransactions & Oii and O and Ojj don’t conflict don’t conflict Then S’ with swapped order OThen S’ with swapped order Ojj O Oi i equivalent to Sequivalent to S

If S can become S’ via swapping nonconflicting If S can become S’ via swapping nonconflicting operationsoperations S is S is conflict serializableconflict serializable

9393

Schedule 2: Concurrent Schedule 2: Concurrent Serializable ScheduleSerializable Schedule

9494

LockingLocking ProtocolProtocolEnsure serializability by associating lock with each data Ensure serializability by associating lock with each data itemitem Follow locking protocol for access controlFollow locking protocol for access control

LocksLocks Shared Shared – T– Tii has shared-mode lock (S) on item Q, T has shared-mode lock (S) on item Q, Tii can read can read

Q but not write QQ but not write Q ExclusiveExclusive – Ti has exclusive-mode lock (X) on Q, T– Ti has exclusive-mode lock (X) on Q, Tii can read can read

and write Qand write Q

Require every transaction on item Q acquire Require every transaction on item Q acquire appropriate lockappropriate lock

If lock already held, new request may have to waitIf lock already held, new request may have to wait Similar to readers-writers algorithmSimilar to readers-writers algorithm

9595

Two-phase Locking ProtocolTwo-phase Locking Protocol

Generally ensures conflict serializabilityGenerally ensures conflict serializability

Each transaction issues lock and unlock Each transaction issues lock and unlock requests in two phasesrequests in two phases Growing – obtaining locksGrowing – obtaining locks Shrinking – releasing locksShrinking – releasing locks

Does not prevent deadlockDoes not prevent deadlock

9696

Timestamp-based ProtocolsTimestamp-based ProtocolsSelect order among transactions in advance – Select order among transactions in advance – timestamp-orderingtimestamp-ordering

Transaction TTransaction Ti i associated with timestamp TS(Tassociated with timestamp TS(T ii) )

before Tbefore Tii starts starts TS(TTS(Tii) < TS(T) < TS(Tjj) if Ti entered system before T) if Ti entered system before Tjj

TS can be generated from system clock or as logical TS can be generated from system clock or as logical counter incremented at each entry of transactioncounter incremented at each entry of transaction

Timestamps determine serializability orderTimestamps determine serializability order If TS(TIf TS(Tii) < TS(T) < TS(Tjj), system must ensure produced ), system must ensure produced

schedule equivalent to serial schedule where Tschedule equivalent to serial schedule where Tii

appears before Tappears before Tjj

9797

Timestamp-based Protocol Timestamp-based Protocol ImplementationImplementation

Data item Q gets two timestampsData item Q gets two timestamps W-timestamp(Q) – largest timestamp of any W-timestamp(Q) – largest timestamp of any

transaction that executed write(Q) transaction that executed write(Q) successfullysuccessfully

R-timestamp(Q) – largest timestamp of R-timestamp(Q) – largest timestamp of successful read(Q)successful read(Q)

Updated whenever read(Q) or write(Q) Updated whenever read(Q) or write(Q) executedexecuted

9898

Timestamp-ordering protocolTimestamp-ordering protocol assures any conflicting assures any conflicting read read and and writewrite executed in timstamp order executed in timstamp order

Suppose Ti executes Suppose Ti executes read(Q)read(Q) If TS(TIf TS(Tii) < W-timestamp(Q), Ti needs to read ) < W-timestamp(Q), Ti needs to read

value of Q that was already overwrittenvalue of Q that was already overwritten

rread ead operation rejected and Toperation rejected and Tii rolled back rolled back

If TS(TIf TS(Tii) ≥ W-timestamp(Q)) ≥ W-timestamp(Q)

read read executed, R-timestamp(Q) set to max(R-executed, R-timestamp(Q) set to max(R-timestamp(Q), TS(Ttimestamp(Q), TS(Tii))))

9999

Timestamp-ordering ProtocolTimestamp-ordering Protocol

Suppose Ti executes write(Q)Suppose Ti executes write(Q) If TS(TIf TS(Tii) < R-timestamp(Q), value Q produced by T) < R-timestamp(Q), value Q produced by T ii

was needed previously and Twas needed previously and T ii assumed it would assumed it would

never be producednever be produced

Write Write operation rejected, Toperation rejected, T ii rolled back rolled back

If TS(TIf TS(Tii) < W-tiimestamp(Q), T) < W-tiimestamp(Q), T ii attempting to write attempting to write

obsolete value of Qobsolete value of Q

WriteWrite operation rejected and T operation rejected and T ii rolled back rolled back Otherwise, Otherwise, write write executedexecuted

100100

Any rolled back transaction TAny rolled back transaction T ii is assigned new is assigned new

timestamp and restartedtimestamp and restarted

Algorithm ensures conflict serializability and Algorithm ensures conflict serializability and freedom from deadlockfreedom from deadlock

101101

Schedule Possible Under Schedule Possible Under Timestamp ProtocolTimestamp Protocol

102102

End of Chapter 6End of Chapter 6

Chapter 6: Process Synchronization

Documents

Transcript of Chapter 6: Process Synchronization