Chapter 10: Mutual Exclusion

1. Chapter 10: Mutual Exclusion Distributed Algorithms Nancy A. Lynch Presented By: R. Whittlesey-Harris

2. Contents • Introduction • Asynchronous Shared Memory Model • Mutual Exclusion Problem • Dijkstra’s Algorithm • Stronger Conditions • Lockout-Free ME Algorithms

3. Introduction • Asynchronous algorithms differ from synchronous algorithms in that they must handle uncertainty due to asynchrony and distribution • The Mutual Exclusion problem exists in both centralized and distributed OSs.

4. Introduction • This chapter presents several mutual exclusion algorithms for the read/write shared memory model • A Lower Bound is given for the number of read/write shared variables required to solve the problem

5. Introduction • Upper and Lower bound results are provided for the case of shared variables that are read-modify-write

6. Asynchronous Shared Memory Model • The system has a collection of processes (1..n) and shared variables • Each process i is some form of state machine with a set statei of states and a subset starti of statesi that indicate the start states • Process i has labeled actions which describe the activities for which it participates • Actions are classified as, input, output, or internal • Internal actions are classified as • Those that involve a single shared memory variable • Those that involve the local computation only

7. Asynchronous Shared Memory Model • Add Figure 10.1

8. Asynchronous Shared Memory Model • Since there are no messages in this model, there are no message-generation functions • The system transition relation, trans, is a set of triples, (s, ,s’), where s and s’ are automaton states • Combination of states for all processes and values for all the shared variables, called “automaton states” •  is the label of an input, output or internal action

9. Asynchronous Shared Memory Model • (s, , s’)  trans • From automaton state s, it is possible to go to automaton state s’ as a result of performing action  • The model allows for non-determinism (for convenience) • System is input-enabled • Input actions can always occur • Controlled by an arbitrary external user • Output and internal steps may be enabled only in a subset of states • Controlled by the system itself

10. Asynchronous Shared Memory Model • Locality restrictions are placed on the set of transitions • For transitions that don’t involve shared memory, the state of the process that performs the action is the only involved • For transitions that involve a process i, and a shared variable x, only the state of process i and the value of x are involved • Enabling of a shared memory action depends only on the process state and not the value of the shared variable accessed

11. Asynchronous Shared Memory Model • Resulting changes to the process state and the variable value may depend on the variable value • Shared variable steps are constrained to be either read or write • Read step involves changing the process state based on its previous state and the value in the variable read; however this variable does not change • Write step involves writing a designated value to a shared variable, overwriting what was there previous. It may also involve changing the process state

12. Asynchronous Shared Memory Model • Processes take steps one at a time in an arbitrary order • Execution is formalized as an alternating sequence, s0,1 ,s1, …., consisting of automaton states alternated with actions belonging to a particular process • May be finite or infinite

13. Asynchronous Shared Memory Model • One exception to the arbitrariness in the order of process steps exists • It is not allowed for a process to stop taking steps when it is supposed to be taking steps • When the process is in a state in which some locally controlled action is enabled

14. Asynchronous Shared Memory Model • The fairness condition for this shared memory system is defined below, • For Process i, we assume one of the following holds, • The entire execution is finite, and in the final state no locally controlled action of process i is enabled • The execution is infinite, and there are either infinitely many occurrences of locally controlled actions of I, ore else infinitely many places where no such action is enabled

15. Mutual Exclusion Problem • Allocation of a single, indivisible, non-shareable resource amongst n users, U1…Un • A user with access to the resource is modeled as being in the critical region, otherwise the user is in the remainder region • A user executes a trying protocol in order to gain access to its critical region

16. Mutual Exclusion Problem • The exit protocol is executed after the user is done with the resource • The user moves in a cycle through its remainder region (R) to its trying region (T) to its critical region (C) and then to its exit region (E) and then back again to (R) • Figure 10.2 shows this cycle

17. Mutual Exclusion Problem • Add Figure 10.2

18. Mutual Exclusion Problem • Processes are numbered 1..n corresponding to one user Ui • Inputs to process i are the tryi and exitiactions • tryi models a request by user Ui for access to a shared resource • exiti models an announcement by user Ui that it is done with the resource

19. Mutual Exclusion Problem • Outputs of the process i are criti, and remi • Critimodels the granting of the resource to Ui • Remitells Ui that it can continue with the rest of its work • Try, crit, exit, and rem are the external actions of the system • The processes are responsible for performing the trying and exit protocols • Each Process, i, acts as an agent on behalf of user Ui

20. Mutual Exclusion Problem • Each user, Ui, 1  i  n, is modeled as a state machine that communicates with its agent process using the tryi, criti, exiti, and remiactions • Figure 10.3 depicts the external interface (external signature)

21. Mutual Exclusion Problem • Insert Figure 10.3

22. Mutual Exclusion Problem • Assume that Uiobeys the cyclic region protocol • We define a sequence of tryi, criti, exitiand remi action to be well-formed for user i if it is a prefix of the cyclically ordered sequence tryi, criti, exiti, remi, tryi,… • Ui is required to preserve the trace property (as defined in 8.5.4) defined by the set of sequences that are well-formed for user i

23. Mutual Exclusion Problem • For executions that observe the cyclic order of actions, we say that Ui is • Initially in its remainder region in between any remi event and the following tryi event • In its trying region in between any tryi event and the following critievent • In its critical region in between any critievent and the following exiti event • Ui should be thought of as being free to use the resource at this time • In its exit region in between any exiti event and the following remievent

24. Mutual Exclusion Problem • Add Figure 10.4

25. Mutual Exclusion Problem • Let A be a shared memory system. For A to solve the mutual exclusion problem, the combination of A and the users must satisfy the following conditions, • Well-formedness: In any execution, and for any I, the subsequence describing the interactions between Ui and A is well-formed for i

26. Mutual Exclusion Problem • Mutual Exclusion: There is no reachable system state (that is a combination of an automaton state for A and states for all the Ui) in which more than one user is in the critical region C • Progress: At any point in a fair execution • (Progress for the trying region) If at least one user is in T and no user is in C, then at some point some user enters C • (Progress for the exit region) If at least one user is in E, then at some later point some user enters R

27. Mutual Exclusion Problem • Shared memory system A solves the mutual exclusion problem provided that it solves the above for every collection of users • Progress condition assumes the system is far (all processes and users continue taking steps) • Fairness is not required for well-formedness and mutual exclusion • Safety properties not liveness

28. Mutual Exclusion Problem • Trace Properties (as defined in section 8.5.2) • E.g., define trace property P, where sig(P) has all the try, crit, exit, and rem actions as outputs and traces(P) is the set of sequences  of these actions that satisfy the following conditions •  is well-formed for each i •  does not contain two crit events without an intervening exit event

29. Mutual Exclusion Problem 3. At any point in , • If some process’s last event is try and no process’s last event is crit, then there is a later crit event • If some process’s last event is exit, then there is a later rem event • An equivalent restatement of the mutual exclusion problem is • The requirement that all combinations B of A with users, fairtraces(B)  traces(P)

30. Mutual Exclusion Problem • Shared Responsibility for progress • Responsibility does not rest only with the protocol (as given by the correctness conditions) but with the users as well • If user Ui gets the resource but never returns it, the entire system grinds to a halt

31. Mutual Exclusion Problem • Lockout • Progress as defined does not guarantee access to a shared resource • It is a “global” notion of progress • some user reaches its critical region • Restricting process activity • A process within the shared memory system can have a locally controlled action enabled only when its user is in the trying or exit regions • A process can be actively engaged in executing the protocol only while it has active requests (each process is an agent for its user)

32. Mutual Exclusion Problem • Read/write shared variables • Also known as registers • In one step, a process can read or write a single shared variable • Two actions involving process i and register x are • (read) Process i reads register x and uses the value read to modify the state of process i • (write) Process i writes a value determined from process i’s state to register x

33. Mutual Exclusion Problem • Lemma 10.1

34. Mutual Exclusion Problem • Proof: • Assume each user always returns the resource • Let  be a finite execution of B ending in s • If process i is either in its trying or exit region in state s and no locally controlled action of process i is enabled in s • Then, no events involving i occur in any execution of B that extend 

35. Mutual Exclusion Problem • Let ’ be a fair execution of B that extends  in which no try events occur after the prefix  • Repeated use of the progress assumption, with the fact that users always return the resource, imply that process i must eventually perform either a criti or a remi action • This contradicts the fact that ’ contains no further actions of i

36. Dijkstra’s Algorithm • First mutual exclusion algorithm for the asynchronous read/write shared memory model – developed in 1965 • Algorithm called DijkstraME

37. Dijkstra’s Algorithm • Add Algorithm

38. Dijkstra’s Algorithm • Shared Variables • Multi-writer/multi-reader variable • turn {1..n} an integer • Single-writer/multi-read variable • flag(i), 1  i  n – values from {0,1,2} • Writable by process i only, but readable by all processes

39. Dijkstra’s Algorithm • First Stage • Set flag = 1 • Check turn repeatedly to see if turn=i • If not & the current owner of turn is not currently active, set turn=i and move to stage two • Second Stage • Set flag = 2 • Check that no other process is in stage 2 • If no other process is in stage 2, get the critical region, otherwise go to the first stage

40. Dijkstra’s Algorithm • After leaving C, lower flag to 0 • The state of each process should consist of the values of its local variables and some other information, including • Temporary variables needed to remember values just read from shared variables • A program counter to say where the process is in its code • Temporary variables introduced by the flow of control of the program (e.g., loop) • A region designation, R ,T , C, or E

41. Dijkstra’s Algorithm • Start state of each process should consist of, • Specified initial values for local variables, • Arbitrary values for temporary variables and • The program counter and region designation indicating the remainder region

42. Dijkstra’s Algorithm • Dijkstra’s algorithm has many ambiguities which should be state explicitly in an automaton • S.A. when a tryi action occurs, i’s program counter should move to state L and i’s region designation should become T

43. Dijkstra’s Algorithm • Dijkstra’s algorithm does not specify which portions of the code comprise of indivisible steps (necessary for reasoning) • Indivisible steps are, • The try, crit, exit, and rem steps at the user interface, • Writes and read to and from the shared variables, and • Some local computations

44. Dijkstra’s Algorithm • Note, the test for whether flag(turn) = 0 does not require two separate reads since turn was just read and a local copy can be used • Dijkstra’s algorithm is rewritten to rid the code of the ambiguities

45. Dijkstra’s Algorithm • Region designation R, T, C, and E are encoded into the program counter • R corresponds to rem • T corresponds to set-flag-1, test-turn, test-flag, set-turn, set-flag-2, check and leave-try • C corresponds to crit; and • E corresponds to reset and leave-exit • Note that each code fragment is performed indivisibly

46. Dikstra’s Algorithm • Add rewritten Algorithm

47. Dijkstra’s Algorithm • Add rewritten algorithm

48. Dijkstra’s Algorithm • Correctness Argument • Lemma 10.2: DijkstraME guarantees well-formedness for each user • Proof: Inspection of code shows that it preserves well-formedness for each user • By assumption, the users also preserve well-formedness, theorem 8.11 implies that the system produces only well-formed sequences

49. Dijkstra’s Algorithm • Lemma 10.3 DijkstraME satisfies mutual exclusion • Proof: Contradiction • Assume that Uiand Uj, i  j, are simultaneously in C in some reachable state • Both processes i and j perform set-flag-2 steps before entering C • Assume set-flag-2icomes first • Thus, flag(i) remains 2 until i leaves C which must be after j enters C • Process j must test flag(i) and find it unequal to 2 before entering C, Contradiction

50. Dijkstra’s Algorithm • Add Figure 10.5