Mutual Exclusion & Semaphores

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. University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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) University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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 */ forever end; University of Colorado – ECEN5043 Process 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; University of Colorado – ECEN5043 Process Management

11. Main program to get everything started begin /* main program */ board = erased; co_begin p1; p2 co_end end Reminder:co_beginandco_endare concurrent programming delimiters that indicate all statements inside the pair can be executed concurrently. University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process Management

14. Problem Solved? • We have addressed • mutual exclusion • deadlock • lockout • Is that enough? (Hint – no! Why not?) University of Colorado – ECEN5043 Process 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? University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process Management

17. 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; program secondattempt;var boarda, boardb: integer; begin /* main */ boarda := 0; boardb := 0; cobegin pa; pb coend end. University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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! ) University of Colorado – ECEN5043 Process Management

20. procedure Pa; begin repeat boarda := 1; while boardb = 1 do ; crit_a; boarda := 0; remainder_a forever end; procedure Pb; begin repeat boardb := 1; while boarda = 1 do ; crit_b; board_b := 0; remainder_b forever end; Program thirdattempt;var boarda, boardb: integer; begin /* main program */ boarda :=0; boardb :=0; cobegin Pa; Pb coend end. University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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.) University of Colorado – ECEN5043 Process Management

24. 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 forever end 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 forever end program fourthattempt; var boarda, boardb : integer; University of Colorado – ECEN5043 Process 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 ... University of Colorado – ECEN5043 Process Management

26. After you. No, after YOU! 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 Pa sets boarda 0 1 Pb sets boardb 0 0 Pa sets boarda 1 0 Pb sets boardb 1 1 ... and on, ad infinitum ... University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process Management

29. 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; Dekker’s Algorithmvar turn: integer; boarda, boardb: integer; University of Colorado – ECEN5043 Process Management

30. turn := b; boarda := 0; /* available */ remainder_a forever end; turn := a; boardb := 0; /* available */ remainder_b forever end; Dekker’s Algorithm (continued) begin /* main program */ boarda := 0; boardb := 0; turn := a; /* arbitrary, someone needs to be first */ cobegin Pa; Pb coend end. University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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; University of Colorado – ECEN5043 Process Management

37. turn := 0; remainder forever end; 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. University of Colorado – ECEN5043 Process 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. University of Colorado – ECEN5043 Process 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 ... University of Colorado – ECEN5043 Process 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) University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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 • Tosurvive 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 University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process Management

44. Not “fair” but it works Char c[] = {1, … , 1}; N is the number of processes P: 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; University of Colorado – ECEN5043 Process 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 …  University of Colorado – ECEN5043 Process 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.) University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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? University of Colorado – ECEN5043 Process 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 University of Colorado – ECEN5043 Process 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). University of Colorado – ECEN5043 Process Management