March 15, 2002University of Colorado – ECEN5043 Process Management 1 Mutual Exclusion & Semaphores...

March 15, 2002 University of Colorado – ECEN5043Process Management

1

Mutual Exclusion & Semaphores

ECEN5043 – Week 2, Lectures 3 and 4

Related topics: mutual exclusion, deadlock, process management, threads, unnecessary delay, liveness.

The 6 solutions of Dijkstra leading to Dekker’s algorithm are taken from Principles of Concurrent

Programming by M. Ben-Ari , Prentice Hall International, 1982.


2

Overview• To solve the problem, we must

– support mutual exclusion– avoid deadlock– avoid lockout – starvation

• Solving the problem well -- primitives– semaphores– mutexes– monitors– message passing– barriers


3

The Mutual Exclusion Problem

• Several processes compete to use a certain resource

• The nature of the resource requires that only one process access it at a time (Examples?)

• Use by one process must exclude others from using it at the same time

• Mutual exclusion constitutes a set of “manners” by which the processes avoid simultaneously accessing the resource (entering their critical sections)


4

Dekker, Dijkstra, and YOU

• There is an early correct solution for 2 processes. It is called Dekker’s algorithm.

• Dijkstra illustrated various bad behaviors with a series of not-quite-right solutions that gradually develop Dekker’s solution. Dijkstra then generalized Dekker’s solution to n processes.

• The not-quite-right solutions will illustrate most of the bugs that a concurrent program can have.


5

Critical Section -- review• This is a logical property – YOU decide what’s critical• For those times when correct behavior requires

indivisibility of a sequence of instructions(indivisible = must not be interrupted by or interleaved

with another process accessing the same resource)• The critical section behaves as an indivisible operation

with respect to SOME set of other processes– As we work through the examples, we will look at

only a 2-process world– Think about: write to a printer; read from & write to

the same disk file; read and write to a data base record


6

Mutual Exclusion, more precisely• Processes P1 and P2 execute in an infinite loop the

same program which has two sections.• P1’s two sections are

– a critical section called crit1– a non-critical section called remainder1

• P2 has two similar sections called crit2 and remainder2

• A critical section is one that must not execute while a corresponding critical section is executing.– For example, this might be the code that

accesses the shared resource that must be accessed by only one process at a time.


7

First Attempt

• Imagine you are in a 2-person family that has one washing machine. This is the shared resource that requires mutually exclusive use. It’s not ok to stop it halfway, remove the other person’s laundry and put your own in. The other person’s use of it excludes yours.

• There is a door with a blackboard and chalk.• If you want to use the washing machine, you look

at the board. – If your number is on it, it is available for you– If the other person’s number is on it, it is that

person’s turn.


8

“Busy Waiting”• If you find a number on the blackboard, you need

to check the board every so often to find out when the washing machine is available.

• Meanwhile, suppose there is nothing else you can do until you have done your laundry.

• You walk in circles in the hallway and every time you pass the laundry room, you check the board.

• This is called busy waiting – purposeless “work”• The board always either shows your number or the

other person’s; it does not have a third state where it is blank.


9

First Process for First Attempt Program

var board: integer; procedure p1;begin

repeat

while board = 2 do /* nothing */ ;crit1; board = 2;remainder1 /* the rest of p1’s work */

foreverend;


10

Second process of First Attempt program

var board: integer;

procedure p2;

begin

repeat

while board = 1 do /* nothing */;

crit2;

board = 1;

remainder2 /* the rest of p2’s work */

forever

end;


11

Main program to get everything started

begin /* main program */

board = erased;

co_begin

p1; p2

co_end

end

Reminder: co_begin and co_end are concurrent programming delimiters that indicate all statements inside the pair can be executed concurrently.


12

Mutual exclusion solved?

• A process enters its critical section only if board = its own number.

• By the common memory assumption (they are both checking the same blackboard), – board will be consistent – it will always equal either 1

or 2– only one process at a time enters the critical section


13

Deadlock solved?• Because board is either 1 or 2, exactly one process will

execute– Both processes cannot be stuck at the while-loops

simultaneously; no deadlock.• Also, every statement takes a finite amount of time so the

critical section that is executing – will terminate – will adjust the board so the other process can execute– therefore, no lockout – neither process can prevent the

other from executing


14

Problem Solved?

• We have addressed– mutual exclusion– deadlock– lockout

• Is that enough?

(Hint – no! Why not?)


15

Inadequate solution Fulfills requirements for a correct concurrent program.

• Does NOT fulfill one of the design requirements.

– These processes are not loosely connected.

– The right to enter the critical section is explicitly passed from one process to the other

• Drawbacks

– P1 is coerced to work at P2’s pace because they must take turns

– If P2 leaves, P1 is deadlocked after all, even if P2 is in its procedure’s remainder2 (prior to reaching its next critical section) outside its critical section when it terminates. This is a liveness issue.

• Ultimately, P1 and P2 are co-routines, not concurrent processes -- what’s the difference?


16

Second Attempt• Give each process its own key to the critical section so if

one leaves, then the other can still enter its critical section. There is now an entrance to the laundry room identified with each process, that is, 2 doors.

• Pa wishes to use the washing machine

– Pa goes to Pb’s entrance periodically until it notes that boardb = 0 signifying Pb is currently not using the washing machine (not in its critical section)

– Pa may enter its critical section (use the machine) after duly registering by chalking a 1 on boarda.

– When Pa is done, it changes boarda to 0 to signify that the critical section is free.


17

program secondattempt;var boarda, boardb: integer;

procedure pa;

begin

repeat

while boardb = 1 do ; boarda := 1;

crit_a;

boarda := 0;

remainder_a

forever

end;

procedure pb;

begin

repeat

while boarda = 1 do ; boardb := 1;

crit_b;

boardb := 0;

remainder_b

forever

end;begin /* main */ boarda := 0; boardb := 0;

cobegin pa; pb coend end.


18

Mutual exclusion still supported?

Task Boarda Boardb

Initially 0 0

Pa checks boardb 0 0

Pb checks boarda 0 0

Pa sets boarda 1 1 0

Pb sets boardb 1 1 1

Pa enters crit_a 1 1

Pb enters crit_b 1 1

Pa and Pb are simultaneously in their critical sections. Oops.


19

Third Attempt• Why did second attempt fail?• Once Pa knows Pb is not in Pb’s critical section, Pa is

going to dash right into Pa’s critical section.• Thus, when Pa passed the while statement, Pa is

essentially in its critical section.• But boarda:= 1 should indicate that Pa is in its critical

section because there may be an arbitrarily long wait between the while and the assignment statement.

• Correct this by advancing the assignment so that boarda = 1 indicates that Pa is in its critical section even before it checks boardb

• Pa is in its critical section the instant that the while is successfully passed. (This time for sure! )


20

Program thirdattempt;var boarda, boardb: integer;

procedure Pa;begin repeat boarda := 1;

while boardb = 1 do ; crit_a; boarda := 0; remainder_a foreverend;

procedure Pb;begin repeat boardb := 1;

while boarda = 1 do ; crit_b; board_b := 0; remainder_b foreverend;

begin /* main program */ boarda :=0; boardb :=0;

cobegin Pa; Pb coend end.


21

Mutual exclusion solved? Yes, but ...Task boarda boardb

Initially 0 0

Pa sets boarda 1 0

Pb sets boardb 1 1



Neither will proceed. Each is waiting for the other to be finished. The program is deadlocked.

Note, however, it does solve the mutual exclusion problem. That is Pa in crit_a implies Pb is not in crit_b and vice versa.


22

Fourth Attempt

• In the third attempt, when Pa writes 1 on boarda to indicate its intention to enter its critical section, it also turns out it is insisting on its right to enter the critical section.

• Setting boarda before checking boardb prevents the violation of mutual exclusion but if Pb is not ready to yield, then Pa should yield.

• Need to overcome this “stubbornness”– Have a process relinquish temporarily its

intention to enter its critical section to give the other process a chance to do so.


23

Attempt Four is Gallant

• Pa writes a 1 on boarda

• Pa checks boardb and, finding a 1 there, too, Pa returns to its board to return the 1 to a 0.

• After a few laps around the hallway, it restores the signal boarda = 1 and tries again.

• (Remember arbitrary interleaving is permissible; the sequence of two assignments to the same variable is not meaningless.)


24

program fourthattempt; var boarda, boardb : integer;procedure Pa;begin repeat boarda = 1;

while boardb = 1 do begin boarda := 0;

/* do nothing for bit */ boarda := 1 /* check again*/ end

crit_a; boarda := 0; remainder_a foreverend

procedure Pb;begin repeat boardb = 1;

while boarda = 1 do begin boardb := 0;

/* do nothing for bit */ boardb := 1 /* try again*/ end

crit_b; boardb := 0; remainder_b foreverend


25

Progress??

• (assume the standard “main program” on the previous slide)

• Mutual exclusion – ok• However, gallant chivalry only works if you are

extremely optimistic ...


26

After you. No, after YOU!Task boarda boardbInitially 0 0

Pa sets boarda 1 0

Pb sets boardb 1 1



Pa sets boarda 0 1

Pb sets boardb 0 0

Pa sets boarda 1 0

Pb sets boardb 1 1 ... and on, ad infinitum ...


27

Characterizing the problem• This could be extended indefinitely• “Liveness” does not hold – neither process will ever

enter its critical section• The problem situation is extremely unlikely ever to

occur• You can’t RELY on that!• We have no way of giving an a priori bound on the

number of iterations that the loops will execute before they are passed– No way of guaranteeing the performance of the

system


28

Is this deadlock or lockout?• Both processes are looping on a protocol which is

certainly not useful computation• Call it lockout

– In the previous attempt, the situation was hopeless– Once it was deadlocked, it would remain

deadlocked• In THIS attempt, the slightest shift in synchronization

will free one of the processes and this will eventually happen in practice.

• It’s “conspiracy”, not hopelessness• But we can’t guarantee correctness if it reaches its

worst-case behavior so we still reject this attempt


29

Dekker’s Algorithmvar turn: integer; boarda, boardb: integer;

procedure Pa;

begin

repeat

boarda := 1;

while boardb = 1 do

if turn = b then

begin

boarda := 0;

while turn = b do ;

boarda := 1 /*try again*/

end;

crit_a; /* continued next slide */

procedure Pb;

begin

repeat

boardb := 1;

while boarda = 1 do

if turn = a then

begin

boardb := 0;

while turn = a do ;

boardb := 1

end;

crit_b;


30

Dekker’s Algorithm (continued)

turn := b;

boarda := 0; /* available */

remainder_a

forever

end;

turn := a;

boardb := 0; /* available */

remainder_b

forever

end;

begin /* main program */

boarda := 0; boardb := 0;

turn := a; /* arbitrary, someone needs to be first */

cobegin Pa; Pb coend

end.


31

Analysis

• Combination of the 1st and 4th attempts.• In the first attempt, we passed the right to enter

the critical section between the processes– One of its problems was that the key to the c.s.

could be lost forever if one of the processes is terminated.

• In the fourth attempt, keeping separate keys leads to the possibility of infinite deferment of one process to the other (after you; no, after YOU!)

• Dekker’s solution is based on the 4th but solves the lockout problem


32

No lockout

• Explicitly passes the right to INSIST on entering the critical solution

• Each process has a separate board so it can go on processing even if one process is terminated (POOF!)

• (We are assuming no process is terminated in its critical section and protocol.)

• There is now an “umpire” board labeled turn.


33

How the Umpire Works• If Pa writes a 1 on boarda and then finds that Pb has

also written a 1 on its board, Pa consults the umpire.• If the umpire has an a written on it, then it is Pa’s turn

to insist– Pa periodically checks Pb’s board.– Pb notes that it is Pb’s turn to defer and gallantly

writes a 0 on its own boardb which Pa will eventually see.

• Pb waits for Pa to terminate its critical section• On termination, Pa frees the c.s. by setting boarda to 0

but also resets turn to b to free Pb from the inner loop and to transfer the right to insist to Pb


34

Proving Liveness

• Mutual exclusion can be proved since the value of turn has no effect on the decision to enter the critical section

• Proving “liveness” is more challenging.

– It is sufficient to prove that if Pa executes boarda := 1 indicating its intention to enter the c.s., then eventually it does so.

• First we prove that if Pa attempts to enter its c.s. but cannot do so, eventually the variable turn is held at value a.

• But if turn is held at a, then Pa can always enter its critical section


35

Dijkstra’s Solution (This is #6)Solution for n processes

const n = ...; /* # of processes */var b, c: array [0 .. n] of boolean

turn: integer;procedure process (i : integer);var j: integer;

ok: boolean;begin repeat b[i] := false; repeat while turn <> i do


36

Dijkstra’s Solution, continued begin

c[i] := true;

if b[turn] then

turn := i

end;

c[i] := false;

ok := true;

for j := 1 to n do

if j <> i then

ok := ok and c[j]

until ok;

crit;

c[i] := true; b[i] := true;


37

turn := 0; remainder

foreverend;begin /* main program */ for turn := 0 to n do begin b[turn] :=true; c[turn] := true end; turn := 0; cobegin process(1); process(2); ... process(n) coend

end.


38

The Need for More Help• Mutual exclusion is one of the simplest problems in

concurrent programming• The solution’s difficulty suggests that it would help to

have programming features that are more powerful than a common memory location for checking.

• In fact, the solution for n processes is so hard that it is primarily of academic interest – compared to the solution one can obtain with semaphores

• Also, the busy wait needed for synchronization is a waste of CPU power.


39

Need to Suspend Blocked Processes

• The better solutions keep a queue (list) of process control blocks for the blocked processes

• Then the overhead is – a small amount of memory– small amount of computation needed to manage

the queue• Final objection to Dekker’s

– It uses a common variable written into by both processes

– Consider, for example, distributed systems ...


40

Process States

• Autonomous processes – independent– Have two states: running and ready-to-run

• Recreate the state diagram for non-autonomous processes– Running (can run and is using the CPU now)– Ready (logically can run but is not)– Blocked (logically cannot [must not] run until

some external event happens)


41

Multi-program Systems• Independent most of the time• Must synchronize at certain points• Must share objects of some kind to communicate• Use of shared objects must be carefully managed

to avoid chaos• CPU is running one sequential process at a time• We think about the processes as concurrent if the

CPU can be arbitrarily switched between them• Other kinds of concurrency

– Interrupt driven (pre-emptive)– Re-entrant code, shared code


42

Minimum Characteristics of a Correct System of Cooperating Tasks

• The “fetch” and “store” of one memory element must be physically indivisible (atomic) operations with respect to all processes.– Reflects behavior of the hardware

• Correct behavior must not depend on – Relative speeds of the processes

• To survive the worst case of arbitrary interrupts that slow a fast process

– Priority of access to shared memory• See Gomaa’s comments about priority inversion• Allows for arbitrary bus-arbitration strategies


43

Semaphore

• An item characterizing a set of critical sections – P: a method of the semaphore that blocks other

processes when one process is executing within the set of critical regions (P = waits)

– V: A method of the semaphore that a process uses to report leaving a critical region in the set. (V = releases or signals)

• Mutual exclusion is a convention – hardware does not enforce it

• Hardware can be used to isolate the overall system from such processes but the portion containing them will still fail if semaphores are ignored


44

Not “fair” but it worksChar c[] = {1, … , 1}; N is the number of processesP: c[i] = 2; /* declare desire to use the resource */

Do {char j;while (turn != i) if (c[turn] = = 1) turn = i;

c[i] = 0;for (j = 0; j < N; j++)if (c[j] = = 0 && j != i) {c[i] = 2; break; }

} while (c[i] = = 2);-------------------------------------------V: c[i] = 1;


45

Notes re previous algorithm

• It works• All fetches and stores are one byte and therefore

indivisible (atomic)• Limited to 256 processes to keep the value of a turn

occupying one byte (indivisible)• Not a “fair” algorithm – why not?• Ugly – needs to know the total number of processes• Complex• Slow• But, hey, other than that …


46

Example of hardware support (not solution)

P: XOR al, al ; al = 0

L: XCHG al, S ; S = 0, al = old value of S

TEST al, al ; check the old value of S

JZ L ; if it was 0, wait some more

-------------------------------------

V MOV S, 1

(And if multiple CPU’s, use the prefix “LOCK” in front of the XCHG command to lock the bus.)

(This is Intel assembly language.)


47

When to wait

• The assembly language example is essentially a busy-wait loop.

• This is acceptable for short waits.• What constitutes a short wait?

– Depends on the nature of every other process’ critical section

– short is “guaranteed” upper limit


48

Length of Critical Section

• “Length” concerns potential time of execution, not number of lines of code– Short = bounded– Long = unbounded (potential of forever)

• Example of an unbounded critical section?


49

CPU as a Shared Resource

• CPU is shared by all processes running on it • P operation hangs up the CPU depriving the

system of an important resource (busy wait)• If there is more than one CPU, it’s ok, provided all

the CPU’s don’t block due to each other• Convention that treats CPU as shared resource:

– A process blocked at the P operation of a short c.s. retains the CPU.

– A process blocked at the P operation of a LONG c.s. gives up the CPU, suspends itself


50

Process Queue• Suppose a process is blocked on a certain semaphore. • Need some way of restarting the process when another

process leaves the critical sections controlled by that semaphore

• Process queues – When a process has to wait, it joins a queue of waiting

processes– Each queue is relative to a specific service or resource

• What does it look like to modify the semaphore for long critical sections so that, if a process fails to get the resource it wants, it put itself into a queue for blocked processes (the blocked-queue).


51

Preconditions & assumptions

• Assume the semaphore on the shared resource is still a one-byte variable

• Assume we have a queue associated with it also. • If the variable is 1, no process is in any critical

sections characterized by the semaphore• If it is 0, some process is in one of the critical

sections characterized by the semaphore.


52

Simple semaphore, blocked-process queue;start out with no one using the resourceS := 1P: xor al, al ; zeroes the register

xchg al, S ; puts 0 in S, puts in al what was in Stest al, al ; “ands” register with self, no stored resjnz PisDone ; nonzero semaphore says c.s. available

;code here to add the current process to the blocked-queue for this section

;switch the CPU to a new processPisDone:--------------------critical section goes here


53

The V side

end of critical section here

------------------

V: ; code for the following

; If the blocked-queue for this semaphore is not empty

; Move the first process in the blocked-queue to the CPU’s ready queue

; else Mov S, 1 ; only free up the resource when

; the queue of blocked processes

; is empty


54

Blocked queue not empty

• NOTE: If the blocked-queue is NOT empty – (there are processes that have already indicated

they want the device and are blocked from using it),

– the semaphore does NOT get set to 1. • That way, if another process suddenly decides it

wants the device, – it will find the semaphore to be 0 and – it will “get in line” by going onto the blocked-

queue rather than grabbing the device and “jumping to the head of the line”.


55

Layered problem

• PROBLEM:

If one process is putting itself onto the blocked-queue just as another process is moving the first item in the blocked-queue over to the ready queue, the pointers that manage position in that queue are likely to get messed up.

In other words, the queue itself is a shared resource. Thus, the blocked queue must be protected by a semaphore as well!


56

The blocked-queue is a resource, too.

• First, think about the queue itself as a shared resource.

• Is access to this resource bounded or unbounded? • Therefore, by convention, the critical section that

is characterized by the semaphore on the queue is a short critical section.


57

Assumptions for new solution• Assume the semaphore on the shared resource is now a

two-byte variable and there is a queue associated with it also.

• If the low byte of the variable – is 1, no process is in any critical sections

characterized by the semaphore; – is 0, some process is in one of the critical sections

characterized by the semaphore. • If the high byte of the variable

– contains 1, then no process is manipulating the blocked-queue;

– is 0, some process is manipulating the blocked-queue.


58

Start with no process accessing either shared resource:S is a 2-item array, each value is 1P: xor al, al

xchg al, Stest al, aljnz PisDone

L: xchg al, S+1 ; this is the semaphore on the queuetest al, aljz L ; wait in a tight loop for the queue to be available

; because the wait is bounded;Add the current process to the blocked-queue for this section; mov S+1, 1;Switch the CPU to a new processPisDone:---------------critical section

P code for shared resource with blocked-queue


59

V code to move processes up in blocked-queue or release semaphore is none blocked

critical section---------------V: xor al, alL1: xchg al, S+1

test al, aljz L1 ; wait in tight loop for queue to be available

; If the blocked-queue for this semaphore is NOT empty; Move the first process to the ready queue, else L2

mov S+1, 1 ; not using the blocked-queuejmp L3

L2: mov S, 1 ; not using the resourceL3:


60

Ready queue

• Discuss the ready queue of process control blocks• Typically the CPU manages this• YOU must manage the semaphores – possibly

with the help of a programming language’s constructs

March 15, 2002University of Colorado – ECEN5043 Process Management 1 Mutual Exclusion & Semaphores...

Documents

Transcript of March 15, 2002University of Colorado – ECEN5043 Process Management 1 Mutual Exclusion & Semaphores...