Operating systemsModule 8

Process Synchronization

1Tami Sorgente

MODULE 8 – PROCESS SYNCHRONIZATION

The Critical-Section Problem Peterson’s Solution Synchronization hardware

2Tami Sorgente

PROCESS SYCHRONIZATION

Processes can execute concurrentlyMay be interrupted at any time, partially completing execution

Concurrent access to shared data may result in data inconsistency

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

3Tami Sorgente

PRODUCER/ CONSUMER (BOUNDED BUFFER)

PRODUCER:

while (true) {/* produce an item in next produced */

while (counter = = BUFFER_SIZE) ;

/* do nothing */

buffer[in] = next_produced;

in = (in + 1) % BUFFER_SIZE;

counter++;

}

CONSUMER:

while (true) {

while (counter = = 0);

/* do nothing */

next_consumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

counter--;

/* consume the item in next consumed */

}

4Tami Sorgente

RACE CONDITION

Several processes access and manipulate the same data outcome of execution depends on the particular order

Producer/consumer :

counter++ could be implemented as

register1 = counterregister1 = register1 + 1counter = register1

counter-- could be implemented as

register2 = counterregister2 = register2 - 1counter = register2

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

S0: producer execute register1 = counter {register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = counter {register2 = 5} S3: consumer execute register2 = register2 – 1 {register2 = 4} S4: producer execute counter = register1 {counter = 6 } S5: consumer execute counter = register2 {counter = 4}

5Tami Sorgente

CRITICAL SECTION PROBLEM

Each process has critical section segment of code

o Process may be changing common variables, updating table, writing file, etc

o When one process in critical section, no other may be in its critical section

Critical section problem

Each process must ask permission to enter critical section in entry section, may follow critical section with exit section

6Tami Sorgente

CRITCAL SECTION

A TYPICAL Process Pi:

7

Entry Section

Exit Section

CS (Critical Section)

do

{

remainder

section

} while(true);

Shared data

Protocol for

ME

Different

Approaches

for

Entry and exit

Ask for

permission

Tami Sorgente

SOLUTION TO CRITICAL SECTION PROBLEM

Mutual Exclusion (ME)

Progress processes NOT executing in the remainder section can participate in decision of who goes in CS, cannot be postponed indefinitely

Bounded waiting – no process should wait for a very long time (fairness) not cause deadlock

8Tami Sorgente

PETERSON’S SOLUTIONBoolean turn = 0;

Boolean flag [2] = {0};

P1 - flag1 turn = 0 //P1

P2 – flag2 turn = 1 //P2

9

flag1 = true;

turn = P2;

while(flag2 && turn==P2);

flag1= false;

CS (Critical Section)

do{

remainder section

} while(true);

Set P1 flag to True

ENTRY

EXITWhen P1 exits

set flag to false

If P2 flag is true and

turn is P2 - wait

Set turn to P2

Tami Sorgente

PETERSON’S SOLUTION

Peterson’s solution (2 processes) solves 3 conditions:

Mutual exclusion –If you are interested and it is your turn – I let you go

Progress – both conditions must be true for process to get stuck in while loop

Bounded waiting – Eventual value of turn decides who will enter

10Tami Sorgente

SYNCHRONIZATION HARDWARE

Many systems provide hardware support for implementing the critical section code.

Idea of lockingo Protecting critical regions via locks

Uniprocessors – could disable interruptso Currently running code would execute without

preemptiono Generally too inefficient on multiprocessor systems

Modern machines provide special atomic hardware instructions

Atomic = non-interruptibleo Either test memory word and set valueo Or swap contents of two memory words

11Tami Sorgente

SOLUTION TO CRITICAL-SECTION

PROBLEM USING LOCKS

do {

acquire lock

critical section

release lock

remainder section

} while (TRUE);

12Tami Sorgente

LOCKS

• Protect a critical section by first acquire()a lock then release() the lock

o Boolean variable indicating if lock is available or not

• Calls to acquire() and release() must be atomic

o Usually implemented via hardware atomic instructions

• This solution requires busy waiting

o This lock therefore called a spinlock

13Tami Sorgente