1. Sept 2011 1 COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 15 More Advanced Program Properties: Temporal logic and jSpin John Gurd, Graham Riley Centre for Novel Computing School of Computer Science University of Manchester

2. Sept 2011 2 Introduction Motivation - Logic and formal modelling – don’t panic! Temporal logic – ‘always’ and ‘eventually’ operators. Use of logic formulae in Spin with Promela. Examples – safety and liveness using LTL –in the critical section problem. –Checking freedom from starvation with non-progress non- critical sections. Conclusion

3. Sept 2011 3 Motivation We have (hopefully) established that parallel programs cannot be debugged using the same techniques as we are used to using with sequential codes. Testing – by running a program multiple times – is simply inadequate to guarantee a program’s correctness under all possible computations. –On current and future machines… I have argued that this is essentially because of the complexity of the state space. –The sheer size in terms of the number of states (‘state explosion’ problem). –The resulting number of paths through the state space, that is, the number of possible computations. A solution: use tools that can explore the state space for us. –Based on a mathematical description of the state space. –A formal logic-based approach has proved successful.

4. Sept 2011 4 Safety properties and assertions We have seen how to check safety properties in Promela models of parallel systems using jSpin. –Such as mutual exclusion and freedom from deadlock. –Typically, introduce auxiliary variables into the model and use assertions. To check these properties in jSpin we use Safety mode and (usually) require verification under the assumption of weak fairness. Linear Temporal Logic (LTL) provides a way to express these and more complex properties which may be checked automatically by jSpin. Next we look at how to use LTL to express and check the safety properties we have looked at but also to check more complex properties, including liveness properties.

5. Sept 2011 5 Logic and Linear Temporal Logic (LTL) We do not need very advanced notions of logic to appreciate the power of the approach. Logic is concerned with the truth or falsehood of propositions or fomulae. –E.g. the proposition (critical<=1) is either true or false. In our models, propositions will contain expressions concerning the variables in the program. –The propostions may become true or false as the computation proceeds from state-to-state. That is they may change value as the control pointers are incremented. –That is, the propositions are concerned with properties of states in the state transition diagram. –We have already seen how auxiliary variables can be added to a model in order to help check properties such as mutual exclusion. Auxiliary variables augment the state space.

6. Sept 2011 6 LTL: always and eventually… For concurrent programs, we need to formalise our notions of ‘always’ and ‘eventually’. –We have already talked of safety properties of programs as properties that are always true (for all states and computations) Always no more than one process in a critical section. Equivalently, never more than one…which is actually what Spin checks. –We have talked of liveness properties as properties that capture the idea that something must eventually happen. A process continually trying to enter its critical section will eventually succeed. There must be some state on all paths in which the property holds.

7. Sept 2011 7 Temporal operators: always and eventually LTL formula are propositions and may be true or false. We are concerned with their values as a computation proceeds through the state space. –This is the ‘time axis’: we do not put an absolute measure (e.g. seconds) on the time axis, we are only concerned with the progress of state transition. We can therefore define the temporal operators ‘always’ and ‘eventually’ in terms of state transition… Consider the proposition, A, (critical<=1).

8. Sept 2011 8 State in which the formula is being evaluated. Not necessarily the beginning of the computation. Time axis is discrete units as transitions occur from state-to- state Formula A is always true from the initial state. Always,symbol: [] []A

9. Sept 2011 9 Formula A is eventually true in some states, after the initial state. Eventually, symbol: <> <>A

10. Sept 2011 10 Compound LTL formulae ‘Eventually, always’: <>[]A At some point, (eventually) it is the case that A becomes true and stays true (always).

11. Sept 2011 11 ‘Always, eventually’: []<>A It is always the case that, from any initial state, A eventually becomes true.

12. Sept 2011 12 Use of LTL formulae in Spin - example We can use spin to verify mutual exclusion using a temporal logic formula. Previously, we used assertions on auxiliary variables placed in the code for the first attempt: –We used either a byte, critical, or booleans, PinCS, QinCS etc. which were written to within the critical section code. –Plus an assertion: assert (critical<=1) placed within the critical section code. Using LTL, we wish to make the assertion: –[] (critical<=1), i.e. ‘always critical should be <=1’ We want to provide this formula to Spin in the ‘LTL Formula’ window. –but Spin requires LTL formulae to use Promela identifiers rather than expressions, so …

13. Sept 2011 13 We define, in our model, an identifier that is true when mutual exclusion holds: –#define mutex (critical <=1) The we enter the temporal logic formula []mutex into the Spin window. Select ‘Translate’ to pre-process the formula for use by Spin. Select ‘Acceptance’ mode and then ‘Verify’. –Acceptance mode asks Spin to check the LTL formula. –Spin will either report no error, or report ‘claim violated’ and leave a trail that can be examined. –The claim is that ‘mutex is true in every state’ or, equivalently, ‘there is never a state in which mutex is false’ This latter is what Spin calls a never claim.

14. Sept 2011 14 The architecture of Spin

15. Sept 2011 15 Examples: using jSpin We can check cs_attempt1.pml for mutual exclusion. We can introduce an error and see the claim violated and examine the trail (e.g. check for turn==1 in both processes). You can confirm that mutual exclusion does not hold for cs_attempt2.pml in a similar way. –Again, the trail gives us evidence as to why.

16. Sept 2011 16 cs_attempt1… byte turn=1; byte critical=0; #define mutex (critical<=1) active proctype P() { do :: printf("Non-critical section P\n"); turn == 1; /* await turn set to 1 */ critical++; printf("Critical section P\n"); critical--; turn = 2; /* set turn to 2 */ od } active proctype Q() { do :: printf("NCS Q\n"); turn == 2; /*await */ critical++; printf("CS Q\n"); critical--; turn = 1; od }

17. Sept 2011 17 LTL and freedom from starvation So far, we have only been able to discuss freedom from starvation by manually examining (fragments of) the state diagram. Now we will see how to use auxiliary variables and LTL identifiers in Promela models to check freedom from starvation. Let us look at cs_attempt1 again… The problem is symmetrical, so we only need to check that one process makes progress.

18. Sept 2011 18 Attempt1: freedom from starvation byte turn=1; bool QinCS; #define nostarve QinCS active proctype P() { do p1: :: printf("Non-critical section P\n"); p2: turn == 1; /* await turn set to 1 */ p3: printf("Critical section P\n"); p4: turn = 2; /* set turn to 2 */ od } active proctype Q() { do q1: :: printf("NCS Q\n"); q2: turn == 2; /*await */ q3: QinCS=true; q4: printf("CS Q\n"); q5: QinCS=false; q6: turn = 1; od }

19. Sept 2011 19 In jSpin… Freedom from starvation is a liveness property so we wish to check that eventually process Q enters its critical section (and sets QinCS=true). We define an identifier: #define nostarve QinCS We wish Spin to check: <>nostarve Enter this formula into the LTL formula window Select Translate. –(Note: If you don’t want an LTL formula, clear the LTL window (and translate). For example, if you want to check something in Safety mode rather than Acceptance mode.) Select Acceptance mode and Verify… Spin will report no errors – why?

20. Sept 2011 20 Progress in the non-critical section The definition of the critical section allows for processes to fail in their non-critical sections. –i.e. they are not required to progress from their non-critical sections. –Such a failure must not stop other processes from entering their critical sections. In earlier lectures we noted that in our example model of attempt1 the non-critical section consists only of a print statement. The print statement will always make progress. –It will not fail and will always complete. So, this version, as we noted before, is free from starvation. Let us introduce some code into the non-critical section of process P that can fail…

21. Sept 2011 21 Code that may not make progress Remember, in an if statement, any statement whose guard is true is eligible for execution. If there is more than one guard true: –one branch will be selected non-deterministically. In the above fragment, the first guard is always true and, if selected, there is no further statement to execute, so the control pointer will move out of the if statement and the process will continue to execute. In the second case, the guard is always true, but if this statement is selected, the guarded statement will not execute until false becomes true! That is, it will never execute, so the process is blocked. No further progress is possible. if :: true -> :: true -> false /* non-progress in NCS */ fi;

22. Sept 2011 22 The Promela statement: false; is equivalent to: The pseudocode statement: await false=true; –Which will never be the case, so the process blocks forever. The promela statement false==true; is also equivalent. –The statement will block until false is true!

23. Sept 2011 23 Non-progress in NCS active proctype Q() { do :: printf("NCS Q\n"); turn == 2; QinCS=true; printf(“CS Q\n"); QinCS=false; turn = 1; od } byte turn=1; bool QinCS; #define nostarve QinCS active proctype P() { do :: printf("NCS P\n"); if :: true :: true -> false /* non-progress in NCS */ fi; turn == 1; printf("CS P\n"); turn = 2; od }

24. Sept 2011 24 Checking with jSpin We proceed as before… –Enter the formula <>nostarve, Translate and Verify in Acceptance mode. This time jSpin reports that the claim is violated. We can examine the trail to see what happened. In the lab exercise, we will examine a full solution to the critical section problem and demonstrate that it is free from starvation even if a process fails to make progress from its non-critical section.

25. Sept 2011 25 More advanced LTL operators The LTL operators always and eventually apply to only a single formula (proposition). Many correctness properties will involve more than one proposition: –For example, we may want to specify that process P enters its critical section at most once before Q enters its critical section. LTL also support an Until operator, U –A U B means that B will eventually become true, and until that point A will be true. LTL also supports the usual logical operators –And (&& in Promela), Or (||) and material implication (->) etc.

26. Sept 2011 26 As a final example, as an alternative to using auxiliary variables, as we have done, an appropriate LTL proposition for checking that Dekker’s algorithm is free from starvation might be: –[]wantp && []turn=1 -> <>[]¬wantq –“if wantp is always true, and turn is also always 1, this implies that, eventually wantq will always be false (and P will be able to enter its critial section)” –In plain english, if P wishes to enter its critical section, eventually it will do so!

27. Sept 2011 27 Conclusion The Spin model checker supports Linear Temporal Logic as a means to express both safety and liveness properties. The two most basic LTL operators are [] (always) and <> (eventually) and these can be used to express useful properties. There are other more advanced operators: Until, Next… Spin can check whether the claim expressed by an LTL formula is satisfied or violated in the state transition diagram of a Promela model. If a claim is violated, Spin leaves a trail which can be used to understand the failure. It is up to the designer to ‘ask good questions’ about properties of the model but, with care, high confidence in the correctness of the design can be gained.