March 15, 2002University of Colorado – ECEN5043 Process Management 1 Mutual Exclusion & Semaphores...
-
date post
21-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of 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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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)
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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;
March 15, 2002 University of Colorado – ECEN5043Process Management
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;
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
14
Problem Solved?
• We have addressed– mutual exclusion– deadlock– lockout
• Is that enough?
(Hint – no! Why not?)
March 15, 2002 University of Colorado – ECEN5043Process Management
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?
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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! )
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
21
Mutual exclusion solved? Yes, but ...Task boarda boardb
Initially 0 0
Pa sets boarda 1 0
Pb sets boardb 1 1
Pa checks boardb 1 1
Pb checks boarda 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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.)
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
25
Progress??
• (assume the standard “main program” on the previous slide)
• Mutual exclusion – ok• However, gallant chivalry only works if you are
extremely optimistic ...
March 15, 2002 University of Colorado – ECEN5043Process Management
26
After you. No, after YOU!Task boarda boardbInitially 0 0
Pa sets boarda 1 0
Pb sets boardb 1 1
Pa checks boardb 1 1
Pb checks boarda 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 ...
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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;
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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;
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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 ...
March 15, 2002 University of Colorado – ECEN5043Process Management
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)
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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;
March 15, 2002 University of Colorado – ECEN5043Process Management
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 …
March 15, 2002 University of Colorado – ECEN5043Process Management
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.)
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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?
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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).
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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”.
March 15, 2002 University of Colorado – ECEN5043Process Management
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!
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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.
March 15, 2002 University of Colorado – ECEN5043Process Management
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
March 15, 2002 University of Colorado – ECEN5043Process Management
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:
March 15, 2002 University of Colorado – ECEN5043Process Management
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