Ch7

Module 7a: Classic Synchronization

BackgroundThe Critical-Section ProblemSynchronization HardwareSemaphoresClassical Problems of SynchronizationMonitors

BackgroundConcurrent access to shared data

may result in data inconsistencyMaintaining data consistency

requires mechanisms to ensure the orderly execution of cooperating processes

(inconsistence data into consistence form is called process synchronization)

Race condition Several processes access and

manipulate the same data concurrently in different order.

we require synchronization of processes.

Race condition

Race condition

Race condition

Race ConditionThe Producer calls while (true) {

while (count == BUFFER_SIZE); // do nothing

// produce an item and put in next Producedbuffer[in] = next Produced;in = (in + 1) % BUFFER_SIZE;counter++;}

Race ConditionThe Consumer calls while (true) {

while (count == 0); // do nothingnextConsumed = buffer[out];out = (out + 1) % BUFFER_SIZE;counter--;// consume the item in nextConsumed}

Race Conditioncount++ could be implemented as

register1 = count register1 = register1 + 1 count = register1

count-- could be implemented as

register2 = count register2 = register2 - 1 count = register2

Consider this execution interleaving: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} S4: producer execute count = register1 {count = 6 } S5: consumer execute count = register2 {count = 4}

Critical-SectionIn concurrent programming a critical section is a piece of code that accesses a shared resource that must not be concurrently accessed by more than one thread of execution.

That part of the program where the shared memory is accessed is called the Critical Section. To avoid race conditions and flawed results, one must identify codes in Critical Sections  in each thread.

Solution to Critical-Section Problem

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

2. Progress - If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then only those processes that are not executing in their remainder sections can participate in the decision on which will enter its critical section next, and this selection cannot be postponed indefinitely.

3. Bounded Waiting - A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted.

Algorithm 1Threads share a common integer

variable turnIf turn==i, thread i is allowed to

executeDoes not satisfy progress

requirementWhy?

Algo #1 FOR PROCES P0 & P1

Do{while (turn != 0);critical sectionturn = 1;remainder section

}while(true);

Do{while (turn != 1);critical sectionturn = 0;remainder section

}while(true);

Let the processes share common variable turn. If turn = 0 process 0 will enter if turn = 1 process 1 will enter the critical section

CODE FOR PROCESS i

Two-task Solution ALGORITHM NO. 1

Let the processes share common variable turn. If turn = 0 process 0 will enter if turn = 1 process 1 will enter the critical section

CODE FOR PROCESS iInt turn;Do{

while (turn != i);critical sectionturn = j;remainder section

}while(true);MUTUAL EXCLUSION IS PRESERVEDPROGRESS REQUIREMENT NOT SATISFIEDTHERE IS A STRICT ALTERNATION

Algorithm 2Add more state information

Boolean flags to indicate thread’s interest in entering critical section

Progress requirement still not metWhy?

ALGO #2 FOR 2 PROCESS. PO& P1Boolean

flag[2]={false,false};

Do{flag [0]= true;while (flag[ I]);critical sectionflag [0] =false;remainder section

}while (true);

Do{

flag [1]= true;while (flag[ 0]);critical sectionflag [1] =false;remainder section

}

while (true);

Two-task SolutionALGORITHM NO. 2CODE FOR PROCESS i

Boolean flag[2]={false, false};Do{

flag [i]= true;while (flag[ j]);critical sectionflag [i] =false;remainder section

}while (true); MUTUAL EXCLUSION IS PRESERVED PROGRESS REQUIREMENT NOT SATISFIED DEAD LOCK IS POSSIBLE SWITCHING THE ORDER OF SETTING AND TESTING WILL NOT SOLVE

THE PROBLEM RATHER MUTUAL EXCLUSION WILL BE VIOLATED

T0: Po sets flag [0]=trueT1: P1 sets flag[1]= trueNote that now Po and P1 are looping

forever in their respective while statements

Algorithm 3Combine ideas from 1 and 2Does it meet critical section requirements?

Peterson’s algo While {Flag[0]=TTurn=1While(turn==1 &&

flag[1]==T);Critical sectionFlag[0]=f}

While {Flag[1]=TTurn=0While(turn==0 &&

flag[0]==T);Critical sectionFlag[1]=f}

Synchronization HardwareMany systems provide hardware

support for critical section codeUniprocessors – could disable

interruptsCurrently running code would execute without

preemptionGenerally too inefficient on multiprocessor systems

Operating systems using this not broadly scalableModern machines provide special

atomic hardware instructionsAtomic = non-interruptable

Either test memory word and set valueOr swap contents of two memory words

boolean TestAndSet(Boolean &target){boolean rv=target;target=true;return rv;}

Synchronization HardwareTEST AND SET INSTRUCTIONSETS THE ARGUMENT TO TRUE AND RETURNS THE OLD VALUE

Boolean lock=false;Do{

while ( Test And Set (lock ) );critical sectionlock = false;remainder section

}while (true)

BOUNDED WAITING REQUIREMENT IS NOT SATISFIED

Do{while ( Test And Set (lock ) );critical sectionlock = false;remainder section

}while (true)

boolean Swap(boolean &a, boolean &b){boolean temp=a;a=b;b=temp;}

Synchronization Hardware

SWAP INSTRUCTIONSWAPS THE CONTENTS OF

TWO MEMORY WORDSBoolean lock=false;Do{

Key =true;while ( key == true)

swap ( lock , key );critical sectionlock = false;remainder section

}while (true)BOUNDED WAITING

REQUIREMENT IS NOT SATISFIED

Do{ Key =true;while ( key == true)

swap ( lock , key );critical sectionlock = false;remainder section

}while (true)

Synchronization HardwareTEST AND SET INSTRUCTION

Boolean waiting [ n]; // initialized to falseBoolean lock ; // initialized to falseDo{

waiting [i] =true;key = true;while ( waiting [ i ] && key )

key = TestAndSet ( lock );waiting [ i ]= false;critical sectionj = (i+1) % n;while ( ( j!=i) && !wating [k] */[j]/*)

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

lock =false;else

waiting [ j]=false;remainder section

}while (true)

Deadlock and StarvationDeadlock – two or more processes are waiting

indefinitely for an event that can be caused by only one of the waiting processes

Let S and Q be two semaphores initialized to 1P0 P1 acquire(S); acquire(Q); acquire(Q); acquire(S);. .. .. . release(S); release(Q); release(Q); release(S);

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