6. promela and the spin model checker

© Stefan Leue 2001 teleDesign of Reactive Systems / Summer 2001 VI - 1 © Stefan Leue 2001

Promela and the SPIN Model Checker

Part 6


Semantics of Promela♦ Semantics Questions

8when does a state s of a Promela Model satisfy an LTL formula ϕ?8 Interpretation of a Promela Model as a state-transition system8asynchronous 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]


Control State Predicates♦ Property Specification for Promela Models

8state 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 S8 in Promela: statements can be labeled


Control State Predicates

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

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 Predicates

♦ Control State Predicate after8after_S holds in state directly following execution of S8 enter: sema?p; crit: skip;

after_enter ⇔ at_crit8not directly supported in Promela

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 }


:: enter: sema?p; /* enter critical section */crit: skip; /* critical section */



Control State Predicates♦ at and after

8 in sequential program segmentsS!; S!"#after_S! ⇔ at_S!"#

8 in branching program segments L!: G! -> atomic{S!; goto L$}after_ L! ⇔ at_L$

♦ in8 in_L

– only meaningful in compound, non-atomic statements♦ In Promela

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


Property Specification in Promela♦ Deadlock

8 the system is in a global state in which no transition is enabled8 typically: "deadly embrace"

8proctype P1 (fromP2, proctype P2 (fromP1,toP2) toP1)

{… {…fromP2?a; fromP1?b;… …toP2!b; toP1!a;… …} }

8analysis– 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?


Property Specification in Promela♦ Livelock

8 the system is in a cyclic execution without making visible progress8 important: define what it means to make progress!

♦ Undesired Termination8 the system terminates in an undesired final state

– channels not empty?– In the middle of processes behaviour definition?


Property Specification in Promela♦ Correctness Claims in Promela

8assert(conditional_expression)

8semantics:– always executable– system execution aborts with an "assertion violation" when conditional_expression is false when executing assert statement

8exampleassert(x != 0);b == n / x;


#define p 0#define v 1chan sema = [0] of { bit };

proctype dijkstra(){ do

:: sema!p -> sema?vod }

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

}}

Property Specification in Promela♦ Global Invariant through assert:


Property Specification in Promela♦ End State Labels

8 in some instances, termination can be wanted for reactive systems8prepending the string "end" in front of the name of a control state

label means that the Promela model may never terminate in this state8when 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 = 1od

}


Property Specification in Promela♦ Progress State Labels

8processes may diverge in infinite loops without ever making any visible progress

8prepending "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-progress-cycle"

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 = 1od }


:: sema?p; /* enter critical section */crit: skip; /* critical section */



Property Specification in Promela♦ Temporal or Never Claims

8possibility to specify temporal properties directly as Büchi automata8Promela model and never claim are executed as synchronous

product8Example: p may never be true infinitely often

– negation: p is eventually always true

8accept: Büchi acceptance condition8never claim may contain arbitrary, side-effect free expressions8also permitted: end, progress, assert8direct specification of never claims may appear unintuitive, therefore

SPIN offers LTL -> never claim translation

never{ do:: skip /* true */:: p -> break /* p */od;

accept: do:: p /* p */od }


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_S4fi;

accept_S4:if:: (! ((c1))) -> goto T0_S4fi;

T0_S4:if:: (! ((c1))) -> goto accept_S4fi;

accept_all:skip

}


Validation Algorithms♦ Implementation of a Model Checker

8 internal representation of input language as transition systems8efficient validation algorithms8presentation follows [Holzmann 95]


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

8data object: tuple (v, v0), where– V: finite set of possible object values– V0 ∈ V: initial value

8side-effect-free expression– does not contain assignments to data objects

8edge label: tuple (C, A), where– C: side-effect free expression (a condition)– A: atomic action, e.g., assignment to data object


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 → L8example LTS:

s0

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

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


Validation Algorithms♦ Expansion

8 idea: map data into the state space8expanded state of an LTS P is an ordered set (si, v1, .., vm) with

– si ∈ P.T.S ("control"), and– vk ∈ P.Dk.V ("data")

8a pair ((si, v1, .., vm), (sk, w1, .., wm)) of expanded states is data consistent for some LTS P if

– (si, sk) ∈ P.T.Eithe 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) = trueithe 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


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

s0

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

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

S0,trueS0,false


Validation Algorithms♦ Traces

8 trace of an TS/LTS T: potentially infinite sequence of states s0, s1, .. such that

– (∀ i)(si, si+1) ∈ T.E8a 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)

8a 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)

8a generic cyclic trace of an TS/LTS T is a finite trace s = s0, s1, .. snsuch that

– (∃ i: 0 ≤ i ≤ n)((si = sn), and– all other states appear only once

8note: generic, finite cyclic or non-cyclic traces form the basis for characterizing counterexamples for safety and liveness properties


Validation Algorithms♦ Asynchronous Product

8modeling concurrency: interleaving semantics8every process (Promela proctype) can be modeled as an (expanded)

LTS, but how do we obtain the global state space?8asynchronous 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 changediwhat 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


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 objectsisubcase 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


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 real-world phenomena with adequate precision

iwe obtain a model that is mathematically very simple, compared to "true concurrency" models

– cf.i[Holzmann 95], p. 27/28i[Manna-Pnueli 92]


Validation Algorithms♦ Modeling other Language Constructs in LTS

8synchronous 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 synchronization8atomic 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 ifirun == 0 (any process may execute), orirun == i (process i is in atomic sequence, and only i may

execute) 8possible to represent all concurrency controlling constructs in

Promela using these (and similar) extensions in the form of an asynchronous product LTS


Validation Algorithms♦ Basic Depth-First Search

8complete exploration of state space8 termination can be proven8complexity

– linear in the number of nodes (which can be exponential in the number of components)

Copyright © 1995 AT&T Corp.


Validation Algorithms♦ Basic Depth-First Search

8efficiency problem– every node needs to be visited twice, once during generation of

the asynchronous product LTS, once during state space searchirequires storage of complete state space

– on-the-fly algorithmiexpand asynchronous product, and search



Validation Algorithms♦ On-the-fly Depth First Search

8z: 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 ficheck property


all successor states in all components

all successor states in one component (i)


Validation Algorithms♦ Basic DFS vs. On-the-fly DFS

8Trade 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 again8 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

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


Validation Algorithms♦ Validation of Invariant Properties with On-the-fly DFS

8predicate 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 printed8example

– p = x ≠ 0

(true, assert(x ≠ 0)) (true, y = z / x)

Si-1 Si Si+1


Validation Algorithms♦ Validation of State Properties

8state properties– assertions– a state is a valid end state– a state is a progress state

8a 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)


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


Validation Algorithms♦ On-the-fly Deadlock Detection

8every state that is not in P.END is a potential deadlock state

current state is terminating

all n processes are in endstate



Validation Algorithm♦ Basic Path Properties

8evaluated along execution paths8 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

8need for cycle-searching algorithms– for accepting cycle detection

itraverse state space to find an accepting state xichange to second state space, set x as seed, and check

whether x is reachable from itself


Validation Algorithms♦ On-the-fly Acceptance Cycle Detection


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, Prentice-

Hall, 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 Operational-

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

6. promela and the spin model checker

Documents