1. Temporal Logic Model- checking with SPIN COMP6004 Stéphane Lo Presti splp@ecs.soton.ac.uk Part 4: Specifications

2. Introduction (1) A specification is (FOLDOC) a document describing how some system should work (a model describes how the system currently works)

3. Introduction (2) Specified in  The model Assertions (local, global) Labels: progress (starvation), acceptance (deadlock), end (livelock)  Correctness properties LTL Formula Büchi automata never claim states cycles

4. Safety and liveness Safety: “nothing bad ever happens”  ex.: deadlock freedom  Find a trace leading to the “bad” thing; if there is not such a trace, the property is satisfied Liveness: “something good will eventually happen”  ex.: termination  Find a loop in which the “good” thing does not happen; if there is not such a loop, the property is satisfied

5. Local properties Assertions assert(P) assert(true) assert(false)

6. Global property Invariant proctype monitor() { assert(P); } Variant forms atomic{ !P -> assert(P);} do :: assert(P) od

7. End-state label How to differentiate between “idle” and “normal end” of a process? Specify valid end-state Statement where the blocking of the process is “normal” (acceptable) Useful when looking for deadlocks

8. Progress-state label The statement indicates that the system makes progress Non-progress may indicate starvation or badly designed system

9. Acceptance-state label Special marking of a state to indicate a “particular” property at that point during the simulation Related to the (Büchi- or ω-) automaton nature of the behaviour of PROMELA models

10. LTL syntax True, false Unary operators: [], <>, ! ( X ) Binary operators: U, &&, ||, ->,

11. Typical LTL formulas (1) [] p always p <> p eventually p p -> (<> q) p implies eventually q p -> (q U r) p implies q until r [] <> p always eventually p <> [] p eventually, always p <> p -> <> q eventually p implies eventually q

12. Typical LTL formulas (2) Useful  ! [] p <> !p  ! <> p [] !p X operator  Next-time-free properties are stutter- invariant

13. Never claims (1) Define an “observer process” (concurrent automaton that never blocks and never communicates) Accept bad behaviours (property violations) (principle: finding a counter-example is simpler/faster than showing that something is always true)

14. Never claims (2) Reference a process state proctypename[pid]@label ex: monitor[123]@progress45

15. Never claims (3) never { S0: do :: A@A1 -> break :: else od; do :: (a ==b) -> break :: else od; accept: true -> goto S0}

16. SPIN’s Slicing Algorithm Will try to suggest optimisations (abstraction, code merging) to the PROMELA model base on the correctness properties