COMP 60611 Fundamentals of Parallel and Distributed Systems

COMP 60611 Fundamentals of Parallel and Distributed Systems Lecture 12 The Critical Section problem John Gurd, Graham Riley Centre for Novel Computing School of Computer Science University of Manchester Sept 2011 1

Introduction • Definition of the critical section problem • Correctness issues – mutual exclusion, deadlock and starvation • Critical look at two attempted solutions • The role of the state diagram in evaluating correctness • The role of the Spin model checker • Summary Sept 2011 2

Critical section problem • Arises when multiple processes need to share resources. • For example, remember the example of interference where two processes were both incrementing the same shared, global variable. – The correct implementation required some form of locking to synchronise the actions of the two processes. • Other examples include: – Access to shared resources such as a printer or monitor screen. – Updates to a shared bank account via multiple cash dispenser/ATMs (and the bank adding interest at the same time!). Sept 2011 3

The general Critical Section problem • We will attempt to solve the general Critical Section (CS) problem using only (atomic) reads and writes to shared memory. – i. e. not using any advanced synchronisation mechanisms! • This problem provides good insight into the major problems involved in developing (correct) concurrent programs: – Mutual exclusion, deadlock, starvation, fairness. • We will also use the model checker j. Spin to explore the algorithms we develop and see how that tool can help with the development of correct solutions. Sept 2011 4

Motivation • In exploring solutions to the CS problem we will focus on the structure of the underlying state space and the state transitions that occur – Remember the state diagram captures the entire state space and all possible computations (execution paths a program may take). – A specific computation (execution of a program) takes a particular path through the state space. • We will seek to interpret the correctness criteria for the CS problem in terms of ‘good’ and ‘bad’ states and the paths a computation may take through the state space. • A good solution will have a state space with no bad states. • An automated model checker will be seen as a vital tool, since state spaces are generally too large for manual checking. Sept 2011 5

Definition of Critical Section problem • Each of N processes is executing in an infinite loop a sequence of statements. • The sequence of statements can be divided into two subsequences: – the non-critical section and the critical section • We consider a two process version – but such ‘toy’ problems are invaluable and the lessons learned can be applied to full size, complex problems. Sept 2011 6

Correctness • Any correct implementation must satisfy: – Mutual exclusion: statements from the critical sections of two or more processes must not be interleaved. – Freedom from deadlock: If some processes are trying to enter their critical sections then one of them must eventually succeed. – Freedom from (individual) starvation: If any process tries to enter its critical section then that process must eventually succeed. • Mutual exclusion and freedom from deadlock are safety properties – Always true throughout a computation. • Freedom from starvation is a liveness or progress property – Something must eventually be true (i. e. happen) in a computation. Sept 2011 7

Outline of a solution • We must provide a synchronisation mechanism that satisfies the correctness specification. • The synchronisation mechanism consists of additional statements that are placed before and after the critical section (CS). – The statements before the CS are called the preprotocol. – The statements after the CS are called the postprotocol. • A structure for the solution is then… Sept 2011 8

Outline of algorithm – two processes global variables p q local variables loop forever non-critical section preprotocol critical section postprotocol Sept 2011 9

Further conditions… • The protocols may require both local and global variables – but we assume that no variables used in the critical and non-critical sections are used in the protocol. • The critical section must progress. – Once a process starts to execute the statements of its critical section it must eventually finish executing them • (this property would have to be proved separately by the developer) • The non-critical section need not progress. – If the control pointer of a process is at or within the non-critical section (NCS), the process may terminate (for some reason) or even enter an infinite loop and not leave the NCS. – Makes the problem quite general! Non progress in one process should not hinder other processes. Sept 2011 10

First attempt - algorithm Sept 2011 11

First attempt – Promela model active proctype Q() { byte turn=1; do active proctype P() { : : printf("NCS Qn"); q 1: q 2: turn == 2; /*await */ p 1: : : printf("Non-critical section Pn"); q 3: printf("CS Qn"); p 2: turn == 1; /* await turn set to 1 */ q 4: turn = 1; p 3: printf("Critical section Pn"); p 4: turn = 2; /* set turn to 2 */ do od } NB: The green labels are NOT part of Promela! Sept 2011 12

Correctness and the state diagram • First, we will look informally at the state diagram to see how the correctness requirements (mutual exclusion, freedom from deadlock and freedom from starvation) may be verified. • Later we will use the model checker j. Spin to support the checking of the properties of the state diagram. • Observe that: – P is in its CS when its control pointer is at p 3 and p 4 – Q is in its CS when its control pointer is at q 3 and q 4 – Remember the control pointer points to the next instruction Sept 2011 13

State diagram for the first attempt Sept 2011 14

Correctness – Mutual exclusion • “Statements from the critical sections of two or more processes must not be interleaved. ” • We can see that there is no state in which the control pointers of both P and Q point to statements in their critical sections. – There is no state with p 3 or p 4 and q 3 or q 4 • Mutual exclusion holds! • We simply search the state diagram – A tool could obviously do this for us. Sept 2011 15

Aside: ‘simultaneous’ statements: in the state diagram - interleaving and multiple paths! p 1, q 1, 1 p 2, q 1, 1 Sept 2011 p 1, q 2, 1 p 2, q 2, 1 16

Freedom from deadlock • “If some processes are trying to enter their critical sections then one of them must eventually succeed. ” • P is trying to enter its CS when the control pointer is at p 2 (awaiting turn to have the value 1. p 2: turn==1) • Q is trying to enter its CS when the control pointer is at q 2 (q 2: turn==2) • This is slightly more tricky, but since the behaviour of processes P and Q is symmetrical, we only have to check what happens for one of the processes, say P. • Freedom from deadlock means that from any state where a process wishes to enter its CS (by awaiting its turn), there is always a path (sequence of transitions) leading to it entering its CS. – i. e. the control pointer can always move to point to p 3. Sept 2011 17

Freedom from deadlock? p 2, q 1, 1 p 2, q 2, 1 p 2, q 1, 2 p 2, q 2, 2 p 2, q 3, 2 There is always a path for P to execute p 2 (turn==1) Sept 2011 p 2, q 4, 2 18

Observation • Note also that once P has entered its CS, and Q is trying to enter its CS, eventually, Q can enter too. – Because of the assumption of progress in a CS (remember that assumption? ), P must eventually leave its CS leading to a state where, if Q tries to enter, it will succeed. – and vice-versa. • Freedom from deadlock in the first attempt holds! • We will see later that, typically, a deadlocked state has no transitions leading from it, i. e. no statement is able to be executed. – Sometimes a cycle of transitions may exist from a state for each process, from which no useful progress in the parallel program can be made. The program is still deadlocked but this situation is sometimes termed ‘livelock’. Every one is ‘busy doing nothing’. Sept 2011 19

Freedom from individual starvation • “If any process tries to enter its critical section then that process must eventually succeed. ” • If a process is wishing to enter its CS (awaiting its turn) and another process refuses to set the turn, the first process is said to be starved. • Possible starvation reveals itself as cycles in the state diagram. • Because the definition of the critical section problem allows for a process to not make progress from its Non-critical section, starvation is, in general, possible in the first attempt… – NOTE, however, that the printf statement in this version of the first attempt will always execute, so there is no starvation in this model. – We will introduce a non critical section that does not guarantee progress in a future lecture and in the lab exercises – and see what j. Spin has to say about it. Sept 2011 20

Freedom from starvation? p 1, q 2, 1 p 2, q 1, 2 Non-progress from p 1 in NCS by P will starve Q! Sept 2011 Q will stay in its loop awaiting turn==2 (similarly for Q from q 1) 21

Summary • Think of turn as a permission resource for entering the critical section. – Its value indicates which process holds the resource. • Some process always holds the resource (turn always 1 or 2) – So some process can always enter the CS • No deadlock! – But if the process holding the resource does not leave its Non-CS – as allowed by the assumptions of the problem – the other process will be starved. • Next we will attempt to ensure that a process staying in its non. CS cannot prevent another process from entering its CS. – Give each process its own variable… Sept 2011 22

Second attempt - algorithm Sept 2011 23

2 nd attempt - observations • The idea is that wantp (wantq) is true from the step where process P (Q) wants to enter its CS until it leaves. • Await statements ensure that one process does not enter its CS while the other process has its flag set. • The problem of failure in the NCS does not occur since a process’ flag will be false in the NCS, so the other process will always succeed in entering its CS. Sept 2011 24

Second attempt - Promela active proctype Q() { bool wantp = false; do bool wantq = false; q 1: : : printf("NCS Qn"); q 2: !wantp; /*await */ p 1: : : printf("Non-critical section Pn"); q 3: wantq = true; p 2: !wantq; /* await turn */ q 3: printf("CS Qn"); p 3: wantp = true; q 4: wantq = false; p 4: printf("Critical section Pn"); p 5: wantp=false; active proctype P() { do od } Sept 2011 25

Mutual exclsusion? • But, what about mutual exclusion etc. – examine the state diagram as before – We don’t need to build all the state diagram. If we find a ‘bad’ state (where both processes are in their CS), that is sufficient. – If there is a computation (path) that includes the bad state, the program is incorrect. – We can ignore the printf statements - since they will always execute – and focus on the logic of the synchronisation variables… • This is known as the ‘reduced’ algorithm. • Note: smaller models have advantages - both for manual reasoning and for performnace in j. Spin. Sept 2011 26

2 nd attempt – reduced algrorithm Sept 2011 27

Fragment of the state diagram – 2 nd attempt Both processes are in their CS at the same time so mutual exclusion does not hold! Sept 2011 28

Observations • Note that we do not necessarily have to have the entire state diagram available at once! – We can build it incrementally – This is useful for an automated model checker • Saves memory (state diagrams can be very big). • Also, as soon as we find a bad state, we can stop. • If there are no bad states though, we will have checked every state in the state diagram. – Another reason for automation. Sept 2011 29

Next attempt at the CS problem? • We will explore the CS problem, including a correct solution to it, in the lab. • We will explore the use of j. Spin in helping to establish the correctness properties. • Instead of constructing the state diagram and examinig it manually, we use j. Spin to explore it for us. • We just have to ask the right questions… Sept 2011 30

Asking questions of j. Spin – auxiliary variables and assertions • To check properties like mutual exclusion we have (informally) talked about the location of the control pointers of the processes – For mutual exclusion to hold, no more than one control pointer should be in the critical section at a time. • The values of control pointers and values of the program variables make up the state of the program. • Thus, proving properties of programs becomes asking Spin to check for certain conditions on the state of the program in any computation (path through the state space) the program may execute. • One way to specify properties is to use auxiliary variables (sometimes called ‘ghost variables’). Sept 2011 31

Auxiliary variables • We add variables to the program that have a meaning in terms • • of the properties we wish to check. The auxiliary variables are not used elsewhere in the program so they cannot affect the correctness of the algorithm. For example, to check mutual exclusion we introduce a counting variable, critical, into the program. – We initialise critical to zero. – We increment critical when a process has entered its critical section. – We decrement critical just before a process leaves its critical section. • If mutual exclusion holds, what is the maximum value the • variable critical should take? We can get Spin to test this using an assertion! Sept 2011 32

Example in attempt 2 bool wantp = false; bool wantq = false; byte critical = 0; /* aux variable */ active proctype Q() { do active proctype P() { : : printf("NCS Qn"); do !wantp; /*await */ : : printf("Non-critical section Pn"); !wantq; /* await turn */ wantq = true; wantp = true; critical++; printf("CS Qn"); printf("Critical section Pn"); assert(critical<=1); critical--; wantq = false; od wantp=false; od } Sept 2011 } 33

Use of j. Spin • Use j. Spin to investigate check the assertion. • Use Verify in Safety mode (with weak fairness selected). • The assertion does not hold! • Look at the trail produced to see why. • We will investigate the use of assertions and j. Spin in lab exercise 3. Sept 2011 34

Conclusion • Focussed on the general critical section problem. – And the correctness properties of mutual exclusion, freedom from deadlock and freedom from starvation. • We have found that the state transition diagram has the answers to whether correctness properties hold. – The state diagram contains all reachable states and all the paths through the state space (i. e. the possible computations). • Properties are evaluated in terms of the state space. • State spaces are generally too large to examine by hand/eye, so tools are essential. • Spin is one such tool and we have seen how to check properties using auxiliary variables and assertions with Spin. Sept 2011 35