Transcript Lecture 13 - School of Computer Science
COMP60621 Designing 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 November 2012 1
• • • • •
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 November 2012 2
• • • •
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.
3 November 2012
• • • •
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.
4 November 2012
• • •
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.
5 November 2012
•
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
checks.
more than one…which is actually what Spin – 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.
6 November 2012
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).
7 November 2012
Always,symbol: []
[]A
Formula A is always true from the initial state. State in which the formula is being evaluated. Not necessarily the beginning of the computation.
November 2012 Time axis is discrete units as transitions occur from state-to state 8
Eventually, symbol: <>
<>A
Formula A is eventually true in some states, after the initial state.
November 2012 9
Compound LTL formulae
‘Eventually, always’: <>[]A
At some point, (eventually) it is the case that A becomes true and stays true (always).
November 2012 10
‘Always, eventually’: []<>A
It is always the case that, from any initial state, A eventually becomes true.
November 2012 11
• • • •
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
which were written to within the critical section code.
etc. – Plus an assertion:
assert (critical<=1)
section code.
placed within the critical 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 … November 2012 12
• • • • 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
window. into the Spin 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
.
November 2012 13
The architecture of Spin
November 2012 14
• • •
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.
15 November 2012
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 } November 2012 } active proctype Q() { do :: printf("NCS Q\n"); turn == 2; /*await */ critical++; printf("CS Q\n"); od critical--; turn = 1; 16
• • • •
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.
17 November 2012
Attempt1: freedom from starvation
p1: p2: p3: p4: byte turn=1; bool QinCS; #define nostarve QinCS active proctype P() { do :: printf("Non-critical section P\n"); od turn == 1; printf("Critical section P\n"); turn = 2; /* await turn set to 1 */ /* set turn to 2 */ } q1: q2: active proctype Q() { do :: printf("NCS Q\n"); turn == 2; /*await */ q3: q4: QinCS=true; printf("CS Q\n"); q5: q6: QinCS=false; turn = 1; od } 18 November 2012
• • • • • • •
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?
19 November 2012
• • • • •
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… 20 November 2012
• • •
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.
21 November 2012
• • • 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!
November 2012 22
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"); od turn = 2; } November 2012 } active proctype Q() { do :: printf("NCS Q\n"); turn == 2; QinCS=true; printf(“CS Q\n"); od QinCS=false; turn = 1; 23
• • •
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.
November 2012 24
• • • •
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.
25 November 2012
• 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!
November 2012 26
• • • • • •
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.
27 November 2012