6. Promela and the SPIN Model Checker

Promela and the SPIN Model Checker

Part 6

Design of Reactive Systems / Summer 2001

VI - 1

© Stefan Leue 2001

tele

Semantics of Promela ♦ Semantics Questions 8 when does a state s of a Promela Model satisfy an LTL formula ϕ? 8 Interpretation of a Promela Model as a state-transition system 8 asynchronous product of the CEFSMs – one CEFSM per proctype instance – conceptually similar to CFSM semantics à la [Brand and Zafiropulo] 8 references – approach to an operational formal semantics definition for Promela given in [Natarajan und Holzmann] ibased on precondition / effect pairs – sketch for the derivation of a state transition system for an asynchronous concurrent programming language given in [Clarke, Grumberg and Peled, Chapter 2]


VI - 2

© Stefan Leue 2001

tele

Control State Predicates ♦ Property Specification for Promela Models 8 state predicates: evaluated over individual states "a process is in the critical section" 8 transition predicates: evaluated over pairs of states "the state q' of the channel after sending of x is equeal to x concatenated with state q of the channel prior to sending x"

♦ State Labeling 8 it may be helpful to be able to refer to control states when specifying state predicates – let S a statement in a concurrent program P, then (σ, i) |= at_S holds if control of p is in s! immediately prior to executing S 8 in Promela: statements can be labeled


VI - 3

© Stefan Leue 2001

tele

Control State Predicates mtype { p, v}; chan sema = [0] of { mtype }; active proctype Dijkstra() { byte count = 1; do :: (count == 1) -> sema!p; count++ :: (count == 0) -> sema?v; count-od } active [3] proctype user() { do :: enter: sema?p; /* enter critical section */ crit: skip; /* critical section */ sema!v; /* leave critical section */ od}

♦ Examples of State Predicates Referring to Control Labels 8 !(at_crit ⇒ count = 1) 8 !◊at_enter (concrete Promela syntax later)


VI - 4

© Stefan Leue 2001

tele

Control State Predicates mtype { p, v}; chan sema = [0] of { mtype }; active proctype Dijkstra() { byte count = 1; do :: (count == 1) -> sema!p; count++ :: (count == 0) -> sema?v; count-od } active [3] proctype user() { do :: enter: sema?p; /* enter critical section */ crit: skip; /* critical section */ sema!v; /* leave critical section */ od}

♦ Control State Predicate after 8 after_S holds in state directly following execution of S 8 enter: sema?p; crit: skip;

after_enter ⇔ at_crit 8 not directly supported in Promela Design of Reactive Systems / Summer 2001

VI - 5

© Stefan Leue 2001

tele

Control State Predicates ♦ at and after 8 in sequential program segments S!; S!"# after_S! ⇔ at_S!"# 8 in branching program segments L!: G! -> atomic{S!; goto L$} after_ L! ⇔ at_L$

♦ in 8 in_L – only meaningful in compound, non-atomic statements

♦ In Promela 8 at, after, in not directly supported – need to be simulated by control state labels – at easiest to emulate


VI - 6

© Stefan Leue 2001

tele

Property Specification in Promela ♦ Deadlock 8 the system is in a global state in which no transition is enabled 8 typically: "deadly embrace" 8 proctype P1 (fromP2, proctype P2 (fromP1, toP2) toP1) {… {… fromP2?a; fromP1?b; … … toP2!b; toP1!a; … … } } 8 analysis – statically: search for cycles in the message and control flow graphs – state traansition model: search for states that do not have a successor state – safety / liveness? Design of Reactive Systems / Summer 2001

VI - 7

© Stefan Leue 2001

tele

Property Specification in Promela ♦ Livelock 8 the system is in a cyclic execution without making visible progress 8 important: define what it means to make progress!

♦ Undesired Termination

8 the system terminates in an undesired final state – channels not empty? – In the middle of processes behaviour definition?


VI - 8

© Stefan Leue 2001

tele

Property Specification in Promela ♦ Correctness Claims in Promela

8 assert(conditional_expression) 8 semantics: – always executable – system execution aborts with an "assertion violation" when conditional_expression is false when executing assert statement 8 example assert(x != 0); b == n / x;


VI - 9

© Stefan Leue 2001

tele

Property Specification in Promela ♦ Global Invariant through assert: #define p 0 #define v 1 chan sema = [0] of { bit }; proctype dijkstra() { do :: sema!p -> sema?v od } byte count; proctype user() { sema?p; count = count+1; skip; /* critical section */ count = count-1; sema!v; skip /* non-critical section */ } proctype monitor() { assert(count == 0 || count == 1) } init { atomic { run dijkstra(); run monitor(); run user(); run user(); run user() }} Design of Reactive Systems / Summer 2001

VI - 10

© Stefan Leue 2001

tele

Property Specification in Promela ♦ End State Labels 8 in some instances, termination can be wanted for reactive systems 8 prepending the string "end" in front of the name of a control state label means that the Promela model may never terminate in this state 8 when the model terminates and all proctype instances are in an "end"-state, then the model is in a permitted terminating state, otherwise "invalid end state" – check for emptyness of channels in termination state is SPIN execution parameter active proctype Dijkstra() { byte count = 1; enddijkstra: do :: (count == 1) -> sema!p; count = 0 :: (count == 0) -> sema?v; count = 1 od }


VI - 11

© Stefan Leue 2001

tele

Property Specification in Promela ♦ Progress State Labels 8 processes may diverge in infinite loops without ever making any visible progress 8 prepending "progress" in front of the name of a control state label means that any cyclic execution of the Promela model must lead through at least one progress labeled state, otherwise "non-progresscycle" mtype { p, v}; chan sema = [0] of { mtype } active proctype Dijkstra() { byte count = 1; end: do :: (count == 1) -> progressdijkstra: sema!p; count = 0 :: (count == 0) -> sema?v; count = 1 od } active [3] proctype user() { do :: sema?p; /* enter critical section */ crit: skip; /* critical section */ sema!v; /* leave critical section */ od} Design of Reactive Systems / Summer 2001

VI - 12

© Stefan Leue 2001

tele

Property Specification in Promela ♦ Temporal or Never Claims 8 possibility to specify temporal properties directly as Büchi automata 8 Promela model and never claim are executed as synchronous product 8 Example: p may never be true infinitely often – negation: p is eventually always true never{ do :: skip /* true */ :: p -> break /* p */ od; accept: do :: p /* p */ od }

8 accept: Büchi acceptance condition 8 never claim may contain arbitrary, side-effect free expressions 8 also permitted: end, progress, assert 8 direct specification of never claims may appear unintuitive, therefore SPIN offers LTL -> never claim translation Design of Reactive Systems / Summer 2001

VI - 13

© Stefan Leue 2001

tele

Property Specification in Promela ♦ LTL Formula after Never Claim Conversion /* * Formula As Typed: [] (t1 -> c1) * The Never Claim Below Corresponds * To The Negated Formula !([] (t1 -> c1)) * (formalizing violations of the original) */ never { /* !([] (t1 -> c1)) */ T0_init: if :: (1) -> goto T0_init :: (! ((c1)) && (t1)) -> goto accept_S4 fi; accept_S4: if :: (! ((c1))) -> goto T0_S4 fi; T0_S4: if :: (! ((c1))) -> goto accept_S4 fi; accept_all: skip } Design of Reactive Systems / Summer 2001

VI - 14

© Stefan Leue 2001

tele

Validation Algorithms ♦ Implementation of a Model Checker 8 internal representation of input language as transition systems 8 efficient validation algorithms 8 presentation follows [Holzmann 95]


VI - 15

© Stefan Leue 2001

tele

Validation Algorithms ♦ Labeled Transition Systems 8 transition system: a triple (S, S0, E) where – S: finite set of states – S0 ∈ S: initial state – E ⊆ S x S: transition relation 8 data object: tuple (v, v0), where – V: finite set of possible object values – V0 ∈ V: initial value 8 side-effect-free expression – does not contain assignments to data objects 8 edge label: tuple (C, A), where – C: side-effect free expression (a condition) – A: atomic action, e.g., assignment to data object


VI - 16

© Stefan Leue 2001

tele

Validation Algorithms ♦ Labeled Transition Systems 8 labeled transition system (LTS): tuple (T, D, L, F), where – T: a transition system – D: finite, ordered set of data objects – L: set of edge labels – F: function mapping transitions to edge labels F: T.E → L 8 example LTS: (C, A) = (x == true, x = not x)

s0

(C, A) = (x == false, x = not x) Design of Reactive Systems / Summer 2001

VI - 17

© Stefan Leue 2001

tele

Validation Algorithms ♦ Expansion 8 idea: map data into the state space 8 expanded state of an LTS P is an ordered set (si, v1, .., vm) with – si ∈ P.T.S ("control"), and – vk ∈ P.Dk.V ("data") 8 a pair ((si, v1, .., vm), (sk, w1, .., wm)) of expanded states is data consistent for some LTS P if – (si, sk) ∈ P.T.E ithe control state transition is one of P – (∀g: 1≤ g ≤ m)(vg ∈ P.Dg.V) ithe first state's variable assignments are appropriate – (∀k: 1≤ k ≤ m)(wk ∈ P.Dk.V) ithe second state's variable assignments are appropriate – P.F(si, sk).C(v1, .., vm) = true ithe enabling condition is true – (∀l: 1≤ l ≤ m)((P.F(si, sk).Al(v1, .., vm)) = wl) ithe change of the data state is as given by the edge label Design of Reactive Systems / Summer 2001

VI - 18

© Stefan Leue 2001

tele

Validation Algorithms ♦ Expansion 8 the expansion of an LTS P is a tuple (S, S0, E), where – S is the set P.T.S x P.D1.V x .. x P.Dm.V – S0 is the tuple (P.T.S0 x P.D1.V0 x .. x P.Dm.V0) – E is the set of all data consistent state pairs in SxS

(C, A) = (x == true, x = not x)

S0, true

s0

S0, false

(C, A) = (x == false, x = not x)


VI - 19

© Stefan Leue 2001

tele

Validation Algorithms ♦ Traces 8 trace of an TS/LTS T: potentially infinite sequence of states s0, s1, .. such that – (∀i)(si, si+1) ∈ T.E 8 a generic non-cyclic trace of an TS/LTS T is a finite trace s = s0, s1, .. sn such that – (∀i,k: 0 ≤ i,k ≤ n)(si ≠ sk) 8 a generic terminating trace of an TS/LTS T is a generic non-cyclic trace s = s0, s1, .. sn such that – (∀t)((t∈T.E ∧ t = (si, sk)) ⇒ (i ≠ n)) (if si has a successor, then it is not the final state of the trace, i.e, the final state in the trace has no successor) 8 a generic cyclic trace of an TS/LTS T is a finite trace s = s0, s1, .. sn such that – (∃i: 0 ≤ i ≤ n)((si = sn), and – all other states appear only once 8 note: generic, finite cyclic or non-cyclic traces form the basis for characterizing counterexamples for safety and liveness properties Design of Reactive Systems / Summer 2001

VI - 20

© Stefan Leue 2001

tele

Validation Algorithms ♦ Asynchronous Product 8 modeling concurrency: interleaving semantics 8 every process (Promela proctype) can be modeled as an (expanded) LTS, but how do we obtain the global state space? 8 asynchronous product of set of (E)LTS P1, .., Pn is an LTS P = (T, D, L, F) where – T.S: P1.T.S x .. x Pn.T.S – T.S0: (P1.T.S0, .., Pn.T.S0) – T.E: {((x1, .., xn), (y1, .., yn)) | (∃k: 1 ≤ k ≤ n) (((xk, yk) ∈ Pk.T.E) ∧ ((∀l ≠ n : 1 ≤ l ≤ n)(xl ≡ yl)))} iwhat is changed iwhat remains the same – D: ∪i = 1, .., n Pi.D – L: ∪i = 1, .., n Pi.L – F: mapping assigning edge label Pk.F(xk,yk) to transition ((x1, .., xn), (y1, .., yn)) for the k selected above Design of Reactive Systems / Summer 2001

VI - 21

© Stefan Leue 2001

tele

Validation Algorithms ♦ Discussion 8 is an interleaving semantics adequate to model concurrent systems? – case 1: concurrent processes do not share common data objects isimultaneous execution is indistinguishable from execution in any order – case 2: concurrent processes do share common date objects isubcase a: data objects are non-distributed entities * there needs to be a control unit that sequentializes concurrent accesses * decompose operations into atomic operations at control unit level * interleaving approach describes everything that can happen accurately isubcase b: data objects are distributed entities * decompose into components * then treat as in subcase a


VI - 22

© Stefan Leue 2001

tele

Validation Algorithms ♦ Discussion 8 is an interleaving semantics adequate to model concurrent systems? – conclusion iwe may need to perform some modeling tricks, e.g., breaking up of operations into lower-level, smaller granularity operations iit is an approach that allows us to model all relevant realworld phenomena with adequate precision iwe obtain a model that is mathematically very simple, compared to "true concurrency" models – cf. i[Holzmann 95], p. 27/28 i[Manna-Pnueli 92]


VI - 23

© Stefan Leue 2001

tele

Validation Algorithms ♦ Modeling other Language Constructs in LTS 8 synchronous rendez-vous message passing – add for each rendez-vous channel a synchronizing global data object Boq and – add tests and operations on Boq to asynchronous product LTS to ensure proper synchronization 8 atomic execution sequences – add an integer object run with 0 ≤ run ≤ #components – label transitions of LTS such that a transition for process i is only enabled if irun == 0 (any process may execute), or irun == i (process i is in atomic sequence, and only i may execute) 8 possible to represent all concurrency controlling constructs in Promela using these (and similar) extensions in the form of an asynchronous product LTS


VI - 24

© Stefan Leue 2001

tele

Validation Algorithms ♦ Basic Depth-First Search

Copyright © 1995 AT&T Corp.

8 complete exploration of state space 8 termination can be proven 8 complexity – linear in the number of nodes (which can be exponential in the number of components) Design of Reactive Systems / Summer 2001

VI - 25

© Stefan Leue 2001

tele

Validation Algorithms ♦ Basic Depth-First Search


8 efficiency problem – every node needs to be visited twice, once during generation of the asynchronous product LTS, once during state space search irequires storage of complete state space – on-the-fly algorithm iexpand asynchronous product, and search Design of Reactive Systems / Summer 2001

VI - 26

© Stefan Leue 2001

tele

Validation Algorithms ♦ On-the-fly Depth First Search

all successor states in all components all successor states in one component (i)


8 z: asynchronous product state – Control(z, i): return control state of i-th component – Data(z): return data values v1, …, vn – Update(z, i, s, f): take z, replace control state of i-th component with s, apply data action f icheck property Design of Reactive Systems / Summer 2001

VI - 27

© Stefan Leue 2001

tele

Validation Algorithms ♦ Basic DFS vs. On-the-fly DFS 8 Trade space complexity (memory) for time-complexity – in On-the-fly DFS one may erase those parts of the state space that are not on the search stack – danger of multiple generation of some states if erased states need to be visited again 8 In practical situations, the size of the complete state space (exponential in the number of concurrent components and data objects) inhibits the use of Basic DFS

♦ Counterexample 8 is a generic non-cyclic trace obtained by PrintStack()


VI - 28

© Stefan Leue 2001

tele

Validation Algorithms ♦ Validation of Invariant Properties with On-the-fly DFS 8 predicate p required to hold in some state si – add function assert(p) to the appropriate LTS edge labels – if p is violated when assert is executed, run will terminate and error trail is printed 8 example – p=x≠0

(true, assert(x ≠ 0))

Si-1


(true, y = z / x)

Si

Si+1

VI - 29

© Stefan Leue 2001

tele

Validation Algorithms ♦ Validation of State Properties 8 state properties – assertions – a state is a valid end state – a state is a progress state 8 a marked transiton system (MTS) is a tuple M=(P, END, PRG, ACC) where – P is an (E)LTS – END ⊆ P.T.S, called "set of valid end states" – PRG ⊆ P.T.S, called "set of progress states" – ACC ⊆ P.T.S, called "set of accepting states" 8 for a given MTS, assume that by default – PRG = ACC = ∅ – END = {s ∈ P.T.S | (∀t : t ∈ P.T.S) ((s, t) ∉ P.T.E)} (all states that don't have a successor state)


VI - 30

© Stefan Leue 2001

tele

Validation Algorithms ♦ Validation of State Properties 8 the asynchronous product of n MTS is an MTS such that – P is the asynchronous product of LTS 1, …, n – END = {(s1, .., sn) ∈ P.T.S | (∀i: 1≤ i ≤ n)(si ∈ Mi.END)} – PRG = {(s1, .., sn) ∈ P.T.S | (∃i: 1≤ i ≤ n)(si ∈ Mi.PRG)} – ACC = {(s1, .., sn) ∈ P.T.S | (∃i: 1≤ i ≤ n)(si ∈ Mi.ACC)}


VI - 31

© Stefan Leue 2001

tele

Validation Algorithms ♦ On-the-fly Deadlock Detection 8 every state that is not in P.END is a potential deadlock state current state is terminating

all n processes are in endstate



VI - 32

© Stefan Leue 2001

tele

Validation Algorithm ♦ Basic Path Properties 8 evaluated along execution paths 8 let R an asynchronous product of a set of MTS – R is free of non-progress cycles if at least one state in the cyclic suffix of any cyclic trace of R.P.T.E in in R.PRG – R is free of accepting cycles if no state of the cyclic suffix of any cyclic trace of R.P.T.E is in R.ACC 8 need for cycle-searching algorithms – for accepting cycle detection itraverse state space to find an accepting state x ichange to second state space, set x as seed, and check whether x is reachable from itself


VI - 33

© Stefan Leue 2001

tele

Validation Algorithms ♦ On-the-fly Acceptance Cycle Detection


VI - 34

© Stefan Leue 2001

tele

Bibliographic References ♦ [Andrews and Schneider] G. Andrews and F. Schneider, Concepts and Notations for Concurrent Programming, Computing Surveys, Vol. 15, No. 1, March 1983 ♦ [Clarke, Grumberg and Peled] E. Clarke, O. Grumberg and D. Peled, Model Checking, MIT Press, Cambridge, 1999 ♦ [Holzmann 91] G. Holzmann, Design and Validation of Computer Protocols, PrenticeHall, 1991 ♦ [Holzmann 93] Tutorial: Design and Validation of Protocols, Computer Networks and ISDN Systems, Vol. 25, No. 9, pp. 981-1017, 1993 ♦ [Holzmann 95] G. Holzmann, The Verification of Concurrent Systems, unpublished manuscript, AT&T Inc., 1995 ♦ [Holzmann 97] G. Holzmann, The Model Checker SPIN, IEEE Transactions on Software Engineering, Vol. 23, No. 5, May 1997 ♦ [Holzmann 00] G. Holzmann, personal communication, 2000. ♦ [Natarajan and Holzmann] V. Natarajan and G. Holzmann, Outline for an OperationalSemantics Definition for PROMELA, in: J.-C. Grégoire, G. Holzmann and D. Peled (eds.), The SPIN Verification System - Proceedings of the Second Workshop on the SPIN Verification System, DIMACS Series in Discrete Mathematics and Theoretical Computer Science, Vol. 32, AMS, 1996. (Postscript available)


VI - 35

© Stefan Leue 2001

tele