ch06 synchronization

8/3/2019 Ch06 Synchronization

1/53

Synchronization


2/53

Synchronization

Background The Critical-Section Problem Petersons Solution Synchronization Hardware Semaphores Classic Problems of

Synchronization Monitors


3/53

Background

Concurrent access to shared data may result indata inconsistency.

Maintaining data consistency requiresmechanisms to ensure the orderly execution ofcooperating processes.


4/53

Producer-Consumer Problem Paradigm for cooperating processes, producer

process produces information that is consumedby a consumerprocess.

One solution to the producer-consumer problemuses shared memory.

To allow producer and consumer processes to runconcurrently, we must have available a buffer of

items that can be filled by the producer andemptied by the consumer.

The producer and consumer must besynchronized, so that the consumer does not try to

consume an item that has not yet been produced.


5/53

Bounded-Buffer Shared-Memory Solution

Shared data#define BUFFER_SIZE 10

Typedef struct {

. . .

} item;

item buffer[BUFFER_SIZE];

int in = 0;

int out = 0;

Solution is correct, but can only useBUFFER_SIZE-1 elements


6/53

Bounded-Buffer Insert() Method

while (true) {

/* Produce an item */

while (((in + 1) % BUFFER_SIZE ) == out)

; /* do nothing -- no free buffers */

buffer[in] = item;

in = (in + 1) % BUFFER SIZE;

{


7/53

Bounded Buffer Remove() Method

while (true) {

while (in == out)

; // do nothing -- nothing toconsume

// remove an item from the buffer

item = buffer[out];

out = (out + 1) % BUFFER SIZE;return item;

{


8/53

Solution to Consumer-ProducerProblem

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

buffers. We can do so by having an integer countthat keeps track of the number of full buffers.Initially, count is set to 0. It is incremented by theproducer after it produces a new buffer and is

decremented by the consumer after it consumesa buffer.


9/53

Producer

while (true) {

/* produce an item and put in

nextProduced */while (count == BUFFER_SIZE)

; // do nothing

buffer [in] = nextProduced;

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

}


10/53

Consumer

while (true) {

while (count == 0)

; // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item innextConsumed

}


11/53

Race Condition

count++ could be implemented as

register1 = countregister1 = register1 + 1count = register1

count-- could be implemented as

register2 = countregister2 = register2 - 1count = register2

Consider this execution interleaving with count = 5 initially:

S0: producer execute register1 = count {register1 =5}

S1: producer execute register1 = register1 + 1{register1 = 6}S2: consumer execute register2 = count {register2 =5}S3: consumer execute register2 = register2 - 1{register2 = 4}


12/53

Solution to Critical-Section

Problem

1.Mutual Exclusion - If process Pi is executing in itscritical section, then no other processes can beexecuting in their critical sections

2.Progress - If no process is executing in its criticalsection and there exist some processes that wishto enter their critical section, then the selection ofthe processes that will enter the critical sectionnext cannot be postponed indefinitely

3.Bounded Waiting - A bound must exist on thenumber of times that other processes are allowedto enter their critical sections after a process hasmade a request to enter its critical section and

before that request is granted


13/53

Mutexes : Mutual Exclusion

{parent process}

P1busy:=false;

P2busy:=false;initiate P1, P2;

end; {mutex}

var P1busy, P2busy : boolean;


14/53


process P1

beginwhile true do

begin

P1busy := true;

while P2busy do {keep testing};

critical-section;

P1busy:=false;other_P1busy_processing;

end{while}

End; {P1}

{parent process}

P1busy:=false;


end; {mutex}



15/53


process P1

beginwhile true do

begin

P1busy := true;


critical-section;

P1busy:=false;other_P1busy_processing;

end{while}

End; {P1}

process P2

begin

while true do

begin

P2busy := true;


critical-section;

P2busy:=false;

other_P2busy_processing;

end{while}

End; {P2}

{parent process}

P1busy:=false;


end; {mutex}



16/53

Petersons Solution

Two process solution Assume that the LOAD and STORE

instructions are atomic; that is, cannot beinterrupted.

The two processes share two variables: int turn;

Boolean flag[2]

The variable turn indicates whose turn itis to enter the critical section.

The flag array is used to indicate if aprocess is ready to enter the criticalsection. flag[i] = true implies that processPi is ready!


17/53

Algorithm for Process Piwhile (true) {

flag[i] = TRUE;

turn = j;

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

CRITICAL SECTION

flag[i] = FALSE;

REMAINDER SECTION

}


18/53

Synchronization Hardware

The critical-section problem can be solved in auni-processor environment if we can forbid

interrupts to occur while a shared variable is

being modified. In this manner, we could besure that the current sequence of instructions

would be allowed to execute in order without

preemption. No other instructions would berun, so no unexpected modifications could be

made to the shared variable.


19/53


This solution is not feasible in a

multiprocessor environment. Disabling

interrupts on a multiprocessor can be

time-consuming, as the message is

passed to all the processors. This

message passing delays entry into each

critical section, and system efficiency

decreases.


20/53


Many machines provide special hardware

instructions that allow us either to test and

modify the content of a word or to swap

the contents of two words, atomically - as

one uninterruptible unit. These special

instructions can be used to solve the

critical-section problem.


21/53

TestAndndSet Instruction

Definition:

boolean TestAndSet (boolean

&target){

boolean rv = target;

target = TRUE;

return rv:}


22/53


The important characteristic is that this

instruction is executed atomically. Thus, if

two TestAndSet instructions are executed

simultaneously, each on a different CPU,

they will be executed sequentially in some

arbitrary order. If the machine supports

the TestAndSet instruction, then we can

implement mutual exclusion by declaring,

a Boolean variable lock, initialized to


23/53

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

while (true) {while ( TestAndSet (lock ))

; /* do nothing

// critical section

lock = FALSE;

// remainder section

}


24/53

Swap Instruction

Definition:

void Swap (boolean &a, boolean &b)

{boolean temp = a;

a = b;

b = temp:

}


25/53


It operates on the contents of two words

and it is executed atomically. If the

machine supports the Swap instruction,

then the mutual exclusion can be

provided by declaring a variable lock and

is initialized to false. In addition, each

process also has a local Boolean variable

key.


26/53

Solution using Swap Shared Boolean variable lock initialized to FALSE; Eachprocess has a local Boolean variable key.

Solution:while (true) {

key = TRUE;

while ( key == TRUE)Swap (lock, key );

// critical section

lock = FALSE;

// remainder section

}


27/53

Semaphore Synchronization tool that does not require busy waiting

Semaphore S integer variable

Two standard operations modify S: wait() and signal()

Originally called P() andV() Less complicated

Can only be accessed via two indivisible (atomic) operations

wait (S) {while S


28/53

Semaphore as General Synchronization Tool

Counting semaphore integer value can range overan unrestricted domain

Binary semaphore integer value can range onlybetween 0

and 1; can be simpler to implement Also known as mutex locks

Can implement a counting semaphore S as a binarysemaphore

Provides mutual exclusion Semaphore S; // initialized to 1

wait (S);

Critical Section

signal (S);


29/53

Semaphore Implementation Must guarantee that no two processes can

execute wait () and signal () on the samesemaphore at the same time

Thus, implementation becomes the criticalsection problem where the wait and signal code

are placed in the crtical section. Could now have busy waiting in critical section

implementation But implementation code is short

Little busy waiting if critical section rarely occupied

Note that applications may spend lots of time incritical sections and therefore this is not a goodsolution.


30/53

Semaphore Implementation with no Busy waiting

With each semaphore there is anassociated waiting queue. Each entry in awaiting queue has two data items: value (of type integer)

pointer to next record in the list

Two operations: block place the process invoking the

operation on the appropriate waitingqueue.

wakeup remove one of processes in thewaiting queue and place it in the readyqueue.


31/53


32/53

Deadlock and Starvation

Deadlock two or more processes are waitingindefinitely for an event that can be caused byonly one of the waiting processes

Let S and Q be two semaphores initialized to 1P

0

P1

wait (S); wait (Q);

wait (Q); wait (S);

. .

. .

. .

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

Starvation indefinite blocking. A process maynever be removed from the semaphore queue inwhich it is suspended.


33/53

Classical Problems of Synchronization

Bounded-Buffer Problem Readers and Writers Problem

Dining-Philosophers Problem


34/53

Bounded-Buffer Problem

Nbuffers, each can hold one item Semaphore mutex initialized to the value

1

Semaphore full initialized to the value 0

Semaphore empty initialized to the valueN.


35/53

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

while (true) {

// produce an item

wait (empty);

wait (mutex);

// add the item to the buffer

signal (mutex);

signal (full);

}


36/53

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

while (true) {

wait (full);

wait (mutex);

// remove an item from buffer

signal (mutex);

signal (empty);

// consume the removed item

}


37/53

Readers-Writers Problem A data set is shared among a number of

concurrent processes Readers only read the data set; they do not

perform any updates Writers can both read and write.

Problem allow multiple readers to read at thesame time. Only one single writer can accessthe shared data at the same time.

Shared Data Data set Semaphore mutex initialized to 1. Semaphore wrt initialized to 1. Integer readcount initialized to 0.


38/53


39/53

Readers-Writers Problem (Cont.) The structure of a reader process

while (true) {

wait (mutex) ;

readcount ++ ;

if (readercount == 1) wait (wrt) ;

signal (mutex)

// reading is performed

wait (mutex) ;

readcount - - ;

if (redacount == 0) signal (wrt) ;

signal (mutex) ;}


40/53


41/53

Dining-Philosophers Problem (Cont.) The structure of Philosopher i:

While (true) {

wait ( chopstick[i] );

wait ( chopStick[ (i + 1) % 5] );

// eat

signal ( chopstick[i] );

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

// think

}


42/53

Problems with Semaphores

Correct use of semaphore operations:

signal (mutex) . wait (mutex)

wait (mutex) wait (mutex)

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


43/53

Monitors A high-level abstraction that provides a convenient and effective

mechanism for process synchronization Only one process may be active within the monitor at a time

monitor monitor-name

{

// shared variable declarations

procedure P1 () { . }

procedure Pn () {}

Initialization code ( .) { }

}

}


44/53

Schematic view of a Monitor


45/53

Condition Variables

condition x, y;

Two operations on a condition variable:

x.wait () a process that invokes the

operation is

suspended.

x.signal ()resumes one of processes(ifany)that

invoked x.wait ()


46/53

Monitor with Condition Variables


47/53

S l ti t Di i Phil h ( t)


48/53

Solution to Dining Philosophers (cont)

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

(state[i] == HUNGRY) &&

(state[(i + 1) % 5] != EATING) ) {

state[i] = EATING ;

self[i].signal () ;

}}

initialization_code() {

for (int i = 0; i < 5; i++)

state[i] = THINKING;

}}

S l ti t Di i Phil h ( t)


49/53

Solution to Dining Philosophers (cont)

Each philosopher Iinvokes theoperationspickup()

and putdown() in the following sequence:

dp.pickup (i)

EAT

dp.putdown (i)


50/53


51/53

Monitor Implementation

For each condition variablex

, we have:

semaphore x-sem; // (initially = 0)

int x-count = 0;

The operation x.waitcan be implemented as:

x-count++;if (next-count > 0)

signal(next);

else

signal(mutex);

wait(x-sem);

x-count--;


52/53

Monitor Implementation

The operation x.signal can be implemented as:

if (x-count > 0) {

next-count++;

signal(x-sem);

wait(next);

next-count--;

}


53/53

Murugan R

Dept. of Computer ApplicationsMES College Marampally

ch06 synchronization

Documents