COMP60621 Designing for Parallelism

COMP60621Designing for Parallelism Lecture 13 More Advanced Program Properties: Temporal logic and jSpin John Gurd, Graham Riley Centre for Novel Computing School of Computer Science University of Manchester

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

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.

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.

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.

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.

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).

Always,symbol: [] Formula A is always true from the initial state. []A 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

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

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

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

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 …

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.

The architecture of Spin

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.

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 }

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.

Attempt1: freedom from starvation 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 } 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 }

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?

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…

Code that may not make progress if :: true -> :: true -> false /* non-progress in NCS */ fi; • 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.

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!

Non-progress in NCS 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 } active proctype Q() { do :: printf("NCS Q\n"); turn == 2; QinCS=true; printf(“CS Q\n"); QinCS=false; turn = 1; od }

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.

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.

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!

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.

COMP60621 Designing for Parallelism