Formale Grundlagen der Informatik 3
Model Checking with Temporal Logic
Reiner Hähnle
26 November 2013
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
1 / 30
Model Checking with Spin
model
name.pml
correctness
properties
-a
verifier
pan.c
C
compiler
executable
verifier
pan
random/ interactive / guided
simulation
FGdI3: Model Checking with Temporal Logic
failing
run
model.trail
TU Darmstadt, Software Engineering
or
eith
er
SPIN
“errors: 0”
131126
2 / 30
Stating Correctness Properties
model
name.pml
correctness
properties
Correctness properties can reside within a Promela model, or outside
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
3 / 30
Stating Correctness Properties
model
name.pml
correctness
properties
Correctness properties can reside within a Promela model, or outside
Stating properties within model using
I assertion statements 4
I meta labels
I
I
I
end labels 4
accept labels
progress labels
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
3 / 30
Stating Correctness Properties
model
name.pml
correctness
properties
Correctness properties can reside within a Promela model, or outside
Stating properties within model using
I assertion statements 4
I meta labels
I
I
I
end labels 4
accept labels
progress labels
Stating properties outside model using
I never claims
I temporal logic formulas
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
3 / 30
Stating Correctness Properties
model
name.pml
correctness
properties
Correctness properties can reside within a Promela model, or outside
Stating properties within model using
I assertion statements 4
I meta labels
I
I
I
end labels 4
accept labels (briefly)
progress labels
Stating properties outside model using
I never claims (briefly)
I temporal logic formulas (today’s main topic)
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
3 / 30
Preliminaries
1. Accept labels in Promela and their relation to Büchi automata
2. Fairness
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
4 / 30
Preliminaries 1: Acceptance Cycles
Definition (Accept Location)
A location marked with an accept label of the form “acceptXXX :”
is called an accept location.
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
5 / 30
Preliminaries 1: Acceptance Cycles
Definition (Accept Location)
A location marked with an accept label of the form “acceptXXX :”
is called an accept location.
Accept locations can be used to specify cyclic behavior
Definition (Acceptance Cycle)
A run which infinitely often passes through an accept location is called
an acceptance cycle.
Acceptance cycles are mainly used in never claims (more later), to define
forbidden infinite behavior
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
5 / 30
Preliminaries 2: Fairness
Does this Promela model terminate in each run?
Demo: fair.pml
byte n = 0;
bool flag = f a l s e ;
a c t i v e proctype P () {
do :: flag -> break ;
:: e l s e -> n = 5 - n
od
}
a c t i v e proctype Q () {
flag = true
}
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
6 / 30
Preliminaries 2: Fairness
Does this Promela model terminate in each run?
Demo: fair.pml
byte n = 0;
bool flag = f a l s e ;
a c t i v e proctype P () {
do :: flag -> break ;
:: e l s e -> n = 5 - n
od
}
a c t i v e proctype Q () {
flag = true
}
Termination guaranteed only if scheduling is (weakly) fair!
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
6 / 30
Preliminaries 2: Fairness
Does this Promela model terminate in each run?
Demo: fair.pml
byte n = 0;
bool flag = f a l s e ;
a c t i v e proctype P () {
do :: flag -> break ;
:: e l s e -> n = 5 - n
od
}
a c t i v e proctype Q () {
flag = true
}
Termination guaranteed only if scheduling is (weakly) fair!
Definition (Weak Fairness)
A run is called weakly fair iff the following holds:
each continuously executable statement is executed eventually.
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
6 / 30
Model Checking of Temporal Properties
Many correctness properties not expressible by assertions
I All properties that involve state changes
Use Temporal Logic to Express Properties Involving State Change
I Even temporal logic not expressive enough to characterize all
properties
In this course: “temporal logic” synonymous with “linear temporal logic”
Today: model checking of properties formulated in temporal logic
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
7 / 30
Beyond Assertions
Locality of Assertions
Assertions talk only about the state at their location in the code
Example
Mutual exclusion enforced by adding assertion to each critical section
critical ++;
a s s e r t ( critical <= 1 ) ;
critical - -;
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
8 / 30
Beyond Assertions
Locality of Assertions
Assertions talk only about the state at their location in the code
Example
Mutual exclusion enforced by adding assertion to each critical section
critical ++;
a s s e r t ( critical <= 1 ) ;
critical - -;
Drawbacks
I No separation of concerns (model vs. correctness property)
I Changing assertions is error prone (easily out of sync)
I Easy to forget assertions:
correctness property might be violated at unexpected locations
I Many interesting properties not expressible via assertions
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
8 / 30
Temporal Correctness Properties
Examples of properties more conveniently expressed as
global properties than as assertions:
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
9 / 30
Temporal Correctness Properties
Examples of properties more conveniently expressed as
global properties than as assertions:
Mutual Exclusion
“critical <= 1 holds throughout any run”
Array Index within Bounds (given array a of length len)
“0 <= i <= len-1 holds throughout any run”
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
9 / 30
Temporal Correctness Properties
Examples of properties more conveniently expressed as
global properties than as assertions:
Mutual Exclusion
“critical <= 1 holds throughout any run”
Array Index within Bounds (given array a of length len)
“0 <= i <= len-1 holds throughout any run”
Examples of properties impossible to express as assertions:
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
9 / 30
Temporal Correctness Properties
Examples of properties more conveniently expressed as
global properties than as assertions:
Mutual Exclusion
“critical <= 1 holds throughout any run”
Array Index within Bounds (given array a of length len)
“0 <= i <= len-1 holds throughout any run”
Examples of properties impossible to express as assertions:
Absence of Deadlock
“If several processes try to enter their critical section,
eventually one of them does so.”
Absence of Starvation
“If one process tries to enter its critical section,
eventually that process does so.”
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
9 / 30
Temporal Correctness Properties
Examples of properties more conveniently expressed as
global properties than as assertions:
Mutual Exclusion
“critical <= 1 holds throughout any run”
Array Index within Bounds (given array a of length len)
“0 <= i <= len-1 holds throughout any run”
Examples of properties impossible to express as assertions:
Absence of Deadlock
“If several processes try to enter their critical section,
eventually one of them does so.”
Absence of Starvation
“If one process tries to enter its critical section,
eventually that process does so.”
All of these are temporal properties ⇒
FGdI3: Model Checking with Temporal Logic
use temporal logic
TU Darmstadt, Software Engineering
131126
9 / 30
Boolean Temporal Logic
Numerical variables in expressions
I Expressions such as 0 <= i <= len-1 contain numerical variables
I
Propositional LTL as introduced so far only knows propositions
I
Slight generalisation of LTL required
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
10 / 30
Boolean Temporal Logic
Numerical variables in expressions
I Expressions such as 0 <= i <= len-1 contain numerical variables
I
Propositional LTL as introduced so far only knows propositions
I
Slight generalisation of LTL required
In Boolean Temporal Logic atomic building blocks are Boolean
expressions over Promela variables, rather than propositional variables
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
10 / 30
Boolean Temporal Logic over Promela
Set ForBTL of Boolean Temporal Formulas
I
(simplified)
All global Promela variables and constants of type bool/bit
are ∈ ForBTL
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
11 / 30
Boolean Temporal Logic over Promela
Set ForBTL of Boolean Temporal Formulas
(simplified)
I
All global Promela variables and constants of type bool/bit
are ∈ ForBTL
I
If e1 and e2 are numerical Promela expressions, then all of
e1==e2, e1!=e2, e1<e2, e1<=e2, e1>e2, e1>=e2 are ∈ ForBTL
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
11 / 30
Boolean Temporal Logic over Promela
Set ForBTL of Boolean Temporal Formulas
(simplified)
I
All global Promela variables and constants of type bool/bit
are ∈ ForBTL
I
If e1 and e2 are numerical Promela expressions, then all of
e1==e2, e1!=e2, e1<e2, e1<=e2, e1>e2, e1>=e2 are ∈ ForBTL
I
If P is a process and l is a label in P, then P@l is ∈ ForBTL
(P@l reads “P is at l”)
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
11 / 30
Boolean Temporal Logic over Promela
Set ForBTL of Boolean Temporal Formulas
(simplified)
I
All global Promela variables and constants of type bool/bit
are ∈ ForBTL
I
If e1 and e2 are numerical Promela expressions, then all of
e1==e2, e1!=e2, e1<e2, e1<=e2, e1>e2, e1>=e2 are ∈ ForBTL
I
If P is a process and l is a label in P, then P@l is ∈ ForBTL
(P@l reads “P is at l”)
I
If φ and ψ are formulas ∈ ForBTL , then all of
! φ, φ && ψ, φ || ψ, φ −> ψ,
[ ]φ, <>φ, φ U ψ
φ <−> ψ
are ∈ ForBTL
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
11 / 30
Semantics of Boolean Temporal Logic
A run σ through a Promela model M is a chain of states
L0 , I0
L1 , I1
L2 , I2
L3 , I3
···
L4 , I4
I
Lj maps each running process to its current location counter
I
From Lj to Lj+1 , only one of the location counters has advanced
(exception: channel rendezvous)
I
Ij maps each variable in M to its current value
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
12 / 30
Semantics of Boolean Temporal Logic
A run σ through a Promela model M is a chain of states
L0 , I0
L1 , I1
L2 , I2
L3 , I3
···
L4 , I4
I
Lj maps each running process to its current location counter
I
From Lj to Lj+1 , only one of the location counters has advanced
(exception: channel rendezvous)
I
Ij maps each variable in M to its current value
Arithmetic and relational expressions are interpreted in states as
expected; e.g. Lj , Ij |= x<y iff Ij (x) < Ij (y)
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
12 / 30
Semantics of Boolean Temporal Logic
A run σ through a Promela model M is a chain of states
L0 , I0
L1 , I1
L2 , I2
L3 , I3
···
L4 , I4
I
Lj maps each running process to its current location counter
I
From Lj to Lj+1 , only one of the location counters has advanced
(exception: channel rendezvous)
I
Ij maps each variable in M to its current value
Arithmetic and relational expressions are interpreted in states as
expected; e.g. Lj , Ij |= x<y iff Ij (x) < Ij (y)
Lj , Ij |= P@l iff
Lj (P) is the location labeled with l
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
12 / 30
Semantics of Boolean Temporal Logic
A run σ through a Promela model M is a chain of states
L0 , I0
L1 , I1
L2 , I2
L3 , I3
···
L4 , I4
I
Lj maps each running process to its current location counter
I
From Lj to Lj+1 , only one of the location counters has advanced
(exception: channel rendezvous)
I
Ij maps each variable in M to its current value
Arithmetic and relational expressions are interpreted in states as
expected; e.g. Lj , Ij |= x<y iff Ij (x) < Ij (y)
Lj , Ij |= P@l iff
Lj (P) is the location labeled with l
Evaluating other formulas ∈ ForBTL in runs σ: see previous lecture
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
12 / 30
Safety Properties
Safety Properties
. . . are formulas of the form [ ]φ
I
State that something good (φ) is guaranteed throughout each run
I
Equivalently: in [ ]¬ψ something bad (ψ) never happens
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
13 / 30
Safety Properties
Safety Properties
. . . are formulas of the form [ ]φ
I
State that something good (φ) is guaranteed throughout each run
I
Equivalently: in [ ]¬ψ something bad (ψ) never happens
Example
TL formula [](critical <= 1)
“it is guaranteed throughout each run that at most one process visits its
critical section at any time”
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
13 / 30
Safety Properties
Safety Properties
. . . are formulas of the form [ ]φ
I
State that something good (φ) is guaranteed throughout each run
I
Equivalently: in [ ]¬ψ something bad (ψ) never happens
Example
TL formula [](critical <= 1)
“it is guaranteed throughout each run that at most one process visits its
critical section at any time”
or, equivalently:
“it will never happen that more than one process visits its critical section”
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
13 / 30
Applying Temporal Logic to Critical Section Problem
We want to verify [](critical<=1) as a correctness property of:
a c t i v e proctype P () {
do :: /* non - critical activity */
atomic {
! inCriticalQ ;
inCriticalP = true
}
critical ++;
/* critical activity */
critical - -;
inCriticalP = f a l s e
od
}
/* similarly for process Q */
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
14 / 30
Model Checking a Safety Property Web I/F
1. Add definition of TL formula to Promela file
Example ltl m {[](critical <= 1) }
General ltl <claim name> { <TL formula> }
we may define more than one formula
2. Load Promela file in web interface
3. If more than one formula defined, fill Name of LTL formula field
I
by default, the first claim is used
4. Ensure Safety mode is selected
5. Select Verify
6. A never claim corresponding to negation of the formula is created
7. (If necessary) limit number of verification steps with Stop after
Demo: safety1.pml, claims m,f
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
15 / 30
Model Checking a Safety Property Web I/F
1. Add definition of TL formula to Promela file
Example ltl m {[](critical <= 1) }
General ltl <claim name> { <TL formula> }
we may define more than one formula
2. Load Promela file in web interface
3. If more than one formula defined, fill Name of LTL formula field
I
by default, the first claim is used
4. Ensure Safety mode is selected
5. Select Verify
6. A never claim corresponding to negation of the formula is created
7. (If necessary) limit number of verification steps with Stop after
Demo: safety1.pml, claims m,f
ltl definitions not part of Ben Ari’s book (Spin≥ 6): ignore 5.3.2, etc.
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
15 / 30
Never Claims
Promela program
transition system T
FGdI3: Model Checking with Temporal Logic
is valid for?
TL formula φ
Buechi autom. for ¬φ
TU Darmstadt, Software Engineering
131126
16 / 30
Never Claims
Promela program
transition system T
is valid for?
TL formula φ
Buechi autom. for ¬φ
To disprove <>φ need to represent an infinite computation
1. Negated TL formula translated to specific Promela process
2. That “never claim” process tries to show the user wrong
3. Büchi automaton derived from “never claim” process
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
16 / 30
Never Claims
Promela program
is valid for?
transition system T
TL formula φ
“Never claim” for ¬φ
not accepted?
Buechi automaton
Buechi automaton
To disprove <>φ need to represent an infinite computation
1. Negated TL formula translated to specific Promela process
2. That “never claim” process tries to show the user wrong
3. Büchi automaton derived from “never claim” process
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
16 / 30
Construction of Never Claims (Example)
Accept Labels
Never claim translated into special Promela process with accept labels
I
I
If one of these reached infinitely often, the claim is disproved
Can be viewed as a “game” between Spin and user:
I
I
I
I
Spin makes forward move in never claim process with accept labels
user makes forward move in Promela program under verification
If an accept label reached infinitely often, the user “lost”
Finiteness guaranteed by cyclicity check
never { /* !( < > q ) */
accept_init : /* passed ∞ often iff []! q holds */
T0_init :
if
:: (! q ) -> goto T0_init
fi
}
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
17 / 30
Execution of Never Claims (Example)
Given a Promela program P over variable q: want to prove P |= <>q
never { /* !( < > q ) */
accept_init : /* passed ∞ often iff []! q holds */
T0_init :
if
:: (! q ) -> goto T0_init
fi
}
q becomes true Spin is blocked at that point and “loses”
q never true Spin loops ∞ often over accept label
resulting in acceptance cycle
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
18 / 30
Execution of Never Claims (Example)
Given a Promela program P over variable q: want to prove P |= <>q
never { /* !( < > q ) */
accept_init : /* passed ∞ often iff []! q holds */
T0_init :
if
:: (! q ) -> goto T0_init
fi
}
q becomes true Spin is blocked at that point and “loses”
q never true Spin loops ∞ often over accept label
resulting in acceptance cycle
General Never Claims
I Promela has specific constructs only for “never claim” processes
I
Some never claims cannot be expressed in temporal logic
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
18 / 30
Model Checking Promela against Temporal Logic
Summary of Model Checking Process with Spin
1. Represent the interleaving of all processes as a single automaton
(only one process advances in each step), called M
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
19 / 30
Model Checking Promela against Temporal Logic
Summary of Model Checking Process with Spin
1. Represent the interleaving of all processes as a single automaton
(only one process advances in each step), called M
2. Construct Büchi automaton (never claim) N C ¬φ for negation of TL
formula φ to be verified
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
19 / 30
Model Checking Promela against Temporal Logic
Summary of Model Checking Process with Spin
1. Represent the interleaving of all processes as a single automaton
(only one process advances in each step), called M
2. Construct Büchi automaton (never claim) N C ¬φ for negation of TL
formula φ to be verified
3. If
Lω (M) ∩ Lω (N C ¬φ ) = ∅
then φ holds in M,
otherwise we have a counterexample
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
19 / 30
Model Checking Promela against Temporal Logic
Summary of Model Checking Process with Spin
1. Represent the interleaving of all processes as a single automaton
(only one process advances in each step), called M
2. Construct Büchi automaton (never claim) N C ¬φ for negation of TL
formula φ to be verified
3. If
Lω (M) ∩ Lω (N C ¬φ ) = ∅
then φ holds in M,
otherwise we have a counterexample
4. To check Lω (M) ∩ Lω (N C ¬φ ) construct intersection automaton
(both automata advance in each step) and search for accepting run
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
19 / 30
Model Checking a Safety Property with Spin directly
Command Line Execution
Make sure ltl <name> { <TL formula> } is in <file>.pml
> spin -a < file >. pml
> gcc -DSAFETY -o pan pan . c
> ./ pan -N <name>
Demo: safety1.pml
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
20 / 30
Liveness Properties
Liveness Properties
. . . formulas of the form <>φ
I
state that something good (φ) eventually happens in each run
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
21 / 30
Liveness Properties
Liveness Properties
. . . formulas of the form <>φ
I
state that something good (φ) eventually happens in each run
Example
<>csp
(with csp a variable only true in the critical section of P)
“in each run, process P visits its critical section eventually”
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
21 / 30
Applying Temporal Logic to Starvation Problem
We want to verify <>csp as a correctness property of:
a c t i v e proctype P () {
do :: /* non - critical activity */
atomic {
! inCriticalQ ;
inCriticalP = true
}
csp = true ;
/* critical activity */
csp = f a l s e ;
inCriticalP = f a l s e
od
}
/* similarly for process Q */
/* there , using csq
*/
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
22 / 30
Model Checking a Liveness Property with Web I/F
1. Load Promela file
2. Ensure that liveness formula is defined in file using ltl
3. If more than one formula defined, fill Name of LTL formula field
I
by default, the first claim is used
4. Ensure Acceptance mode is selected (Spin will search for accepting
cycles through the never claim)
5. For the moment uncheck weak fairness (discussion later)
6. Select Verify
Demo: liveness1.pml
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
23 / 30
Verification Fails
Verification fails!
Why?
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
24 / 30
Verification Fails
Verification fails!
Why?
Liveness property on one process “had no chance” to be always reached
Not even weak fairness was switched on!
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
24 / 30
Model Checking Liveness with Weak Fairness
Always check weak fairness when verifying liveness
1. Load Promela file
2. Ensure that liveness formula is defined in file using ltl
3. If more than one formula defined, fill Name of LTL formula field
I
by default, the first claim is used
4. Ensure Acceptance mode is selected (Spin will search for accepting
cycles through the never claim)
5. Ensure weak fairness is checked
6. Select Verify
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
25 / 30
Model Checking Liveness with Spin directly
Command Line Execution
Make sure ltl <name> { <TL formula> } is in <file>.pml
> spin -a < file >. pml
> gcc -o pan pan . c
> ./ pan -a -f [ - N < name >]
-a acceptance cycles, -f weak fairness
Demo: liveness1.pml
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
26 / 30
Limitation of Weak Fairness
Verification fails again!
Why?
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
27 / 30
Limitation of Weak Fairness
Verification fails again!
Why?
Weak fairness is too weak . . .
Definition (Weak Fairness)
A run is called weakly fair iff the following holds:
each continuously executable statement is executed eventually.
Note that !inCriticalQ, !inCriticalP are not continuously executable!
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
27 / 30
Limitation of Weak Fairness
Verification fails again!
Why?
Weak fairness is too weak . . .
Definition (Weak Fairness)
A run is called weakly fair iff the following holds:
each continuously executable statement is executed eventually.
Note that !inCriticalQ, !inCriticalP are not continuously executable!
Restriction to weak fairness is principal limitation of Spin
The only way to show liveness of our example is to rewrite the model
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
27 / 30
Temporal Model Checking without Ghost Variables
We want to verify mutual exclusion without using ghost variables
bool inCriticalP = f a l s e , inCriticalQ = f a l s e ;
a c t i v e proctype P () {
do :: atomic {
! inCriticalQ ;
inCriticalP = true
}
cs :
/* critical activity */
inCriticalP = f a l s e
od
}
/* similar for process Q with same label cs : */
ltl m { []!( P@cs && Q@cs ) }
Demo: noGhost.pml
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
28 / 30
Liveness Revisited
Label expressions often remove the need for ghost variables
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
29 / 30
Liveness Revisited
Label expressions often remove the need for ghost variables
I
Specify liveness (i.e., termination) of fair.pml using labels
I
Prove claim termination
I
Weak fairness is sufficient
Demo: fair2.pml
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
29 / 30
Literature for this Lecture
Ben-Ari Chapter 5
except Sections 5.3.2, 5.3.3, 5.4.2
(#define and -f to write claims replaced with ltl)
FGdI3: Model Checking with Temporal Logic
TU Darmstadt, Software Engineering
131126
30 / 30