quo vadis explicit-state model checking
TRANSCRIPT
Quo Vadis Explicit-State Model Checking
Jiří Barnat
Masaryk UniversityCzech Republic
Computer Controlled Era
ObservationOur lives are driven by a number of computer systems.Computer systems tend to have various defects.
System design errors and flawsCould be dangerous.Could be expensive.Could be embarrassing.
Most expensive computer bugsTherac-25Arian 5Pentium FDIV bug
SOFSEM 2015, January 28th 2/68
Computer Controlled Era
ObservationOur lives are driven by a number of computer systems.Computer systems tend to have various defects.
System design errors and flawsCould be dangerous.Could be expensive.Could be embarrassing.
Most expensive computer bugsTherac-25Arian 5Pentium FDIV bug
SOFSEM 2015, January 28th 2/68
Computer Controlled Era
ObservationOur lives are driven by a number of computer systems.Computer systems tend to have various defects.
System design errors and flawsCould be dangerous.Could be expensive.Could be embarrassing.
Most expensive computer bugsTherac-25Arian 5Pentium FDIV bug
SOFSEM 2015, January 28th 2/68
Computer Controlled Era
ObservationOur lives are driven by a number of computer systems.Computer systems tend to have various defects.
System design errors and flawsCould be dangerous.Could be expensive.Could be embarrassing.
Most expensive computer bugsTherac-25Arian 5Pentium FDIV bug
SOFSEM 2015, January 28th 2/68
Classical Development Scheme
SW Production PhasesRequirements AnalysisDesignImplementationTesting
Error Detection By TestingIncomplete.Limited detection of concurrency flaws.40–50% of total development effort.Quite late in development cycle.
SOFSEM 2015, January 28th 3/68
Beyond Testing
We should formally prove correctness ...Cannot be automated in general.Extremely expensive, even if computer-assisted.Done rarely.
Can we do more than testing?SimulationsInformal verification activitiesSemi-automated formal verification methods
SOFSEM 2015, January 28th 4/68
Industry is Aware of the Problem
IntelFormal verification in development of Core i7 processor.Coverage testing for core CPU parts was entirely dropped.Multiple formal verification activities employed instead.
Formal verification activities involvedSymbolic simulation.Model checking.Computer assisted theorem proving.
SOFSEM 2015, January 28th 5/68
Industry is Aware of the Problem – cont.
Avionics IndustrySafety critical systems.DO-178B certification process.Upgraded recently to DO-178C.
Motivation for UpgradeCurrent technology trends in software code developmentrequire new verification and certification approaches.Application of formal verification techniques become validfor the process of certification.
SOFSEM 2015, January 28th 6/68
Industry is Aware of the Problem – cont.
iFEST projectEU funded project: 16 000 000 Eur, 1450 PM21 partners: ABB, Siemens, Thales, Honeywell, MU, . . .Reduce total development cost and time-to-market by20%.Integration and early verification.
SOFSEM 2015, January 28th 7/68
Model Checking
ProsFormal verification method.Can be partly automated.Applicable at design phase.Verification of parallel programs.
ConsProves certain correctness properties only.Requires formalised inputs.Is computationally expensive.
SOFSEM 2015, January 28th 8/68
Outline
Need for VerificationModel CheckingParallel and DistributedLLVM-Based VerificationControl-Explicit Data-Symbolic ApproachConclusions
SOFSEM 2015, January 28th 9/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 10/68
Discrete Distributed System & State Space Graph
channel {byte} c[0];
process A {byte a;state q1,q2,q3;init q1;transq1→q2 { effect a=a+1; },q2→q3 { effect a=a+1; },q3→q1 { sync c!a; effect a=0; };
}
process B {byte b,x;state p1,p2,p3,p4;init p1;transp1→p2 { effect b=b+1; },p2→p3 { effect b=b+1; },p3→p4 { sync c?x; },p4→p1 { guard x==b; effect b=0, x=0; };
}
SOFSEM 2015, January 28th 11/68
Example of System Execution
State: []; A:[q1, a:0]; B:[p1, b:0, x:0]0 〈0.0〉: q1 → q2 { effect a = a+1; }1 〈1.0〉: p1 → p2 { effect b = b+1; }Command:1—————————————————————State: []; A:[q1, a:0]; B:[p2, b:1, x:0]0 〈0.0〉: q1 → q2 { effect a = a+1; }1 〈1.1〉: p2 → p3 { effect b = b+1; }Command:1—————————————————————State: []; A:[q1, a:0]; B:[p3, b:2, x:0]0 〈0.0〉: q1 → q2 { effect a = a+1; }Command:0—————————————————————State: []; A:[q2, a:1]; B:[p3, b:2, x:0]0 〈0.1〉: q2 → q3 { effect a = a+1; }Command:0—————————————————————State: []; A:[q3, a:2]; B:[p3, b:2, x:0]0 〈0.2&1.2〉: q3 → q1 { sync c!a; effect a = 0; }
p3 → p4 { sync c?x; }Command:0—————————————————————State: []; A:[q1, a:0]; B:[p4, b:2, x:2]
SOFSEM 2015, January 28th 12/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 13/68
Property Specification
ObservationInput/output behaviour specification cannot cover manyinteresting properties of reactive or parallel systems.
Linear Time SpecificationDescribes when a single system execution is valid.
Linear Time CorrectnessSystem is a set of (infinite) system executions.System is correct if it has no invalid system execution.
SOFSEM 2015, January 28th 14/68
Linear Temporal Logic
Atomic propositionsStatements about system states.
(x > 0), (x ! = y), . . .
OperatorsBoolean operators∧, ∨, =⇒ , . . .
Modal operatorsϕU ψ : ϕ•−→ϕ•−→ϕ•−→ϕ•−→ψ•−→• · · ·F ϕ : •−→•−→•−→•−→ϕ•−→• · · ·G ϕ : ϕ•−→ϕ•−→ϕ•−→ϕ•−→ϕ•−→ϕ• · · ·
SOFSEM 2015, January 28th 15/68
Examples of LTL Formulae
StabilityAfter some time a holds forever.F ( G(a) )
ResponseThere is a reaction b to every stimuli a.G( a =⇒ F(b) )
Infinite repetitionThere is infinitely many states in the infinite execution forwhich a holds true.G( F(a) )
SOFSEM 2015, January 28th 16/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 17/68
LTL Model Checking Procedure
ObservationHaving a single system execution and LTL property, weneed an automatic decision procedure to check whetherthe execution satisfies the property or not.
Does π satisfy G(a =⇒ F (b))?
π = a,b• −→b•−→a•−→a,b• −→b•−→b• · · ·
SOFSEM 2015, January 28th 18/68
LTL Model Checking Procedure
ObservationHaving a single system execution and LTL property, weneed an automatic decision procedure to check whetherthe execution satisfies the property or not.
Does π satisfy G(a =⇒ F (b))?
π = a,b• −→b•−→a•−→a,b• −→b•−→b• · · ·
FortunatelySet of runs satisfying an LTL formula is a ω-regular.We can employ finite state machines to recognise validexecutions.But system executions may be infinite!
SOFSEM 2015, January 28th 18/68
Büchi Automata in LTL Model Checking
Büchi automatonFinite state machine with accepting states.Accepts if it enters accepting state infinitely many times.Cycle in the automaton containing accepting state.
LTL To Büchi AutomataVardi & Wolper, 1986
SOFSEM 2015, January 28th 19/68
Decision Procedure for LTL MC
Idea InformallyConsider Büchi automaton recognising all invalid runs.Synchronously executed with the system as a monitor.Accepts system runs violating the specification.
Formal ProcedureBüchi automata Asys and Aspec
System is correct if L(Asys) ⊆ L(Aspec)L(Asys) ⊆ L(Aspec)⇐⇒ L(Asys×(¬spec)) = ∅Büchi emptiness problem.Accepting cycle detection in a directed graph.
SOFSEM 2015, January 28th 20/68
Accepting Cycle
SOFSEM 2015, January 28th 21/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 22/68
State Space Explosion Problem
The ProblemThe state space graph tends to grow exponentially withthe size of the description of the distributed system.There is a limit to what can be model-checked.
SOFSEM 2015, January 28th 23/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 24/68
Model Checking Scheme
Verification Failure
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 24/68
Solutions to State Space Explosion
The ProblemThe state space graph tends to grow exponentially withthe size of the description of the distributed system.There is a limit to what can be model-checked.
SolutionsAbstractionsState space reductionsState compression and compactionStateless model checkingSymbolic approachDistributed-memory processing...
SOFSEM 2015, January 28th 25/68
Solutions to State Space Explosion
The ProblemThe state space graph tends to grow exponentially withthe size of the description of the distributed system.There is a limit to what can be model-checked.
SolutionsAbstractionsState space reductionsState compression and compactionStateless model checkingSymbolic approachDistributed-memory processing...
SOFSEM 2015, January 28th 25/68
Outline
Need for VerificationModel CheckingParallel and DistributedLLVM-Based VerificationControl-Explicit Data-Symbolic ApproachConclusions
SOFSEM 2015, January 28th 26/68
Distributed Memory Environment
HardwareNetwork of workstations – clusters.Large amount of aggregate memory.Parallel processing.
Distributed Memory State Space GenerationState space graph is given implicitly with functions to
generate initial stategenerate immediate successors of a stateidentify accepting states
States are distributed among workstations a priory usingstatic partitioning function.
SOFSEM 2015, January 28th 27/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space graph is partitioned with a shared hash-basedfunction. One of the nodes is owner of the initial state.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationSuccessors of the initial state are generated by the owningworkstation. States belonging to a others are sent out.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space generation proceeds in parallel on allworkstations, until all states are expanded.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space generation proceeds in parallel on allworkstations, until all states are expanded.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space generation proceeds in parallel on allworkstations, until all states are expanded.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space generation proceeds in parallel on allworkstations, until all states are expanded.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space generation proceeds in parallel on allworkstations, until all states are expanded.
II
III
SOFSEM 2015, January 28th 28/68
Distributed-Memory Processing
Distributed-Memory State Space GenerationState space generation proceeds in parallel on allworkstations, until all states are expanded.
II
III
SOFSEM 2015, January 28th 28/68
Serial Algorithms in Trouble
Nested DFS algorithmTwo interleaved DFS procedures:
1st identifies reachable accepting states,2nd test each accepting state for self-reachability.
2nd (nested) procedure is started from an accepting state,when the 1st procedure backtracks from it (DFSpostorder).
DFS postorderInherently sequential problem.Optimal, parallel, scalable algorithm is unlikely to exist.Not maintained by parallel DFS procedure.
SOFSEM 2015, January 28th 29/68
Serial Algorithms in Trouble continued
Nested DFS algorithmUnsuitable for parallel processing.
Other optimal algorithmsTarjan’s algorithm for SCC decomposition.Suffer from the same DFS-postorder problem.
SOFSEM 2015, January 28th 30/68
Parallel Algorithms for Accepting Cycle Detection
RequirementsMust be scalable, hence cannot rely on DFS-postorder.Must outperform optimal serial algorithms.
Building Blocks for Parallel AlgorithmsGraph traversal procedures.Value iteration procedures.
Parallel Algorithms for Accepting Cycle DetectionAlgorithm employing computation of MAPAlgorithm employing OWCTY Elimination
SOFSEM 2015, January 28th 31/68
Algorithm MAP
4 > 2 >
1 62 5
3 4
Algorithm assumes that accepting states are linearly ordered.
SOFSEM 2015, January 28th 32/68
Algorithm MAP
44
22
4 > 2 >
1 62 5
3 4
Maximal Accepting Predecessor (MAP)map(v) = max{⊥, u | (u, v) ∈ E+ ∧ A(u)}
SOFSEM 2015, January 28th 32/68
Algorithm MAP
44
22
4 > 2 >
1 62 5
3 4
map(v) = v =⇒ accepting cycle
SOFSEM 2015, January 28th 32/68
Computing MAP
A
B
4 > 2 >
1 62 5
3 4
Two workers A and B.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
4 > 2 >
1 62 5
3 4
Each worker processes its own states.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
4 > 2 >
1 62 5
3 4
Each worker processes its own states.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
4 > 2 >
1 62 5
3 4
Non local states are sent over.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
2
24 > 2 >
1 62 5
3 4
States are processed in parallel.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
22
224 > 2 >
1 62 5
3 4
States are processed in parallel.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
4
22
24 > 2 >
1 62 5
3 4
States are processed in parallel.
SOFSEM 2015, January 28th 33/68
Computing MAP
A
B
44
22
4 > 2 >
1 62 5
3 4
States are processed in parallel.
SOFSEM 2015, January 28th 33/68
Algorithm MAP
2 > 4 >
1 62 5
3 4
What if 2 > 4 ?
SOFSEM 2015, January 28th 34/68
Algorithm MAP
22
222 > 4 >
1 62 5
3 4
Accepting cycle undetected.
SOFSEM 2015, January 28th 34/68
Algorithm MAP
22
222 > 4 >
1 62 5
3 4
If no accepting is cycle found, then maximal accepting verticescannot be part of an accepting cycle.
SOFSEM 2015, January 28th 34/68
Algorithm MAP
4 >
1 62 5
3 4
Maximal accepting vertices marked as non-accepting.
SOFSEM 2015, January 28th 34/68
Algorithm MAP
444 >
1 62 5
3 4
Repeat until accepting cycle is found orthere are no accepting vertices.
SOFSEM 2015, January 28th 34/68
Algorithm MAP
444 >
1 62 5
3 4
Succeeding iterations localised to subgraphswith the same value of MAP.
SOFSEM 2015, January 28th 34/68
Algorithm MAP – subgraphs
0 > 1 > 2 > 4 >
65
4
2
0
1
3
Demonstration of decomposition into subgraphs.
SOFSEM 2015, January 28th 35/68
Algorithm MAP – subgraphs
1 1
1
1
0 00 > 1 > 2 > 4 >
65
4
2
0
1
3
First iteration.No accepting cycle found.
SOFSEM 2015, January 28th 35/68
Algorithm MAP – subgraphs
1 1
1
1
0 00 > 1 > 2 > 4 >
65
4
2
0
1
3
Leading maximal accepting vertices marked as non-accepting.Accepting vertex v is leading if ∃u : map(u) = v .
SOFSEM 2015, January 28th 35/68
Algorithm MAP – subgraphs
0 0
1 1
1
1
2 > 4 >
65
4
2
0
1
3
Leading maximal accepting vertices marked as non-accepting.Accepting vertex v is leading if ∃u : map(u) = v .
SOFSEM 2015, January 28th 35/68
Algorithm MAP – subgraphs
0 0
1 1
1
1
2 > 4 >
65
4
2
0
1
3
Decomposition into subgraphs according to the value of map.In the next iteration referred to as oldmap value.
SOFSEM 2015, January 28th 35/68
Distributed-Memory Systems – MAP Scalability
Cores Runtime (sec) Efficiency1 1052.5 100%64 23.0 72%128 13.1 63%256 8.9 46%
SOFSEM 2015, January 28th 36/68
OWCTY Algorithm
A
B
Idea: Compute set of states preceded by an accepting cycle.If the set is empty, there is no accepting cycle in the graph.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
Initially, all states belong to the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
Phase 1: Unmark states unreachable from accepting states asthey cannot be part of the target set, and ...
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
0
Phase 1: for states reachable from accepting states computetheir indegree with respect to states remaining in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
1
0
Phase 1: for states reachable from accepting states computetheir indegree with respect to states remaining in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
1 1
10
Phase 1: for states reachable from accepting states computetheir indegree with respect to states remaining in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
12
2
0
Phase 1: for states reachable from accepting states computetheir indegree with respect to states remaining in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
12
2
0
Phase 1: for states reachable from accepting states computetheir indegree with respect to states remaining in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
12
2
Phase 2: Unmark states with indegree 0 as they cannotbe part of the target set, and ...
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
1 1
1
Phase 2: update indegree of remaining states in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
1 1
1
Phase 2: update indegree of remaining states in the set.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1
1 1
1
Phases 1 and 2 are repeated until fix point is reached.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1 1
2nd iteration after Phase 1.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1 1
2nd iteration after Phase 2.Fixpoint has been reached.
SOFSEM 2015, January 28th 37/68
OWCTY Algorithm
A
B
1 1
Accepting cycle exists.
SOFSEM 2015, January 28th 37/68
Distributed-Memory Systems – OWCTY Scalability
Cores Runtime (sec) Efficiency1 631.7 100%64 13.3 74%128 7.4 67%256 5.0 49%
SOFSEM 2015, January 28th 38/68
Parallel Algorithms – Overview
Complexity Optimality On-The-Fly
Nested DFS O(N+M) Yes YesMAP Algorithm O(N.N.(N+M)) No YesOWCTY Algorithmgeneral LTL properties O(N.(N+M)) No Noweak LTL properties O(N+M) Yes No
OWCTY +first round of MAPgeneral LTL properties O(N.(N+M)) No Yesweak LTL properties O(N+M) Yes Yes
N – number of statesM – number of transitions
SOFSEM 2015, January 28th 39/68
State Space Explosion Problem
The ProblemThe state space graph tends to grow exponentially withthe size of the description of the distributed system.There is a limit to what can be model-checked.
Solutions
AbstractionState space reductionsState compression and compactionSymbolic approachDistributed-memory processing...
SOFSEM 2015, January 28th 40/68
State Space Explosion Problem
The ProblemThe state space graph tends to grow exponentially withthe size of the description of the distributed system.There is a limit to what can be model-checked.
Solutions
AbstractionState space reductionsState compression and compactionSymbolic approachDistributed-memory processing...
SOFSEM 2015, January 28th 40/68
Partial Order Reduction (POR)
Orders execution of independent actions among processes ofthe distributed system.
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Orders execution of independent actions among processes ofthe distributed system.
Distributed system definition
Process Bb1 b2 b3
a2a1Process A
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Orders execution of independent actions among processes ofthe distributed system.
Unreduced State Space Graphb1 b2 b3
a1
a2
b1
b1
b2
b2
b3
b3
a1 a1 a1
a2 a2 a2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Suppose that order of execution of actions a1, b1 and b2 isirrelevant with respect to the property to be verified.
Unreduced State Space Graphb1 b2 b3
a1
a2
b1
b1
b2
b2
b3
b3
a1 a1 a1
a2 a2 a2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Suppose that order of execution of actions a1, b1 and b2 isirrelevant with respect to the property to be verified.
Unreduced State Space Graphb1 b2 b3
a1
a2
b1
b1
b2
b2
b3
b3
a1 a1 a1
a2 a2 a2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
By postponing execution of selected independent action (e.g.a1) the state space graph is reduced.
Unreduced State Space Graphb1 b2 b3
a1
a2
b1
b1
b2
b2
b3
b3
a1 a1 a1
a2 a2 a2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
By postponing execution of selected independent action (e.g.a1) the state space graph is reduced.
Reduced State Space Graphb1 b2 b3
b2
b2
b3
b3
a1 a1 a1
a2 a2 a2
b1
a1
b1
a2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
By postponing execution of selected independent action (e.g.a1) the state space graph is reduced.
Reduced State Space Graphb1 b2 b3
b3
b3
a1 a1
a2 a2
a1 a1
b1
a2
b1
a2
b2
b2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
The postponing of actions is computed locally and onlyneeds the respective state itself.
Reduced State Space Graphb1 b2 b3
b3
b3
a1 a1
a2 a2
a1 a1
b1
a2
b1
a2
b2
b2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Ample set – actions executed for a given state.Ample(s) = enabled(s) ⇒ s is fully expanded.
Reduced State Space Graphb1 b2 b3
b3
b3
a1 a1
a2 a2
a1 a1
b1
a2
b1
a2
b2
b2
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Postponed action must be eventually executed, otherwise thereduction is incorrect.
Unreduced State Space Graph
b1 b2 b3
a1
b1 b2 b3
a1 a1 a1
b4
b4
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Postponed action must be eventually executed, otherwise thereduction is incorrect.
Permanent Postponing Problem
b1 b2 b3
b1 b2 b3
a1 a1 a1
b4
b4
a1
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Postponed action must be eventually executed, otherwise thereduction is incorrect.
Permanent Postponing Problem
b1 b2 b3
b1 b2 b3
a1 a1
b4
b4
a1 a1
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Postponed action must be eventually executed, otherwise thereduction is incorrect.
Permanent Postponing Problem
b1 b2 b3
b1 b2 b3
a1
b4
b4
a1 a1 a1
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Postponed action must be eventually executed, otherwise thereduction is incorrect.
Permanent Postponing Problem
b1 b2 b3
b4
a1 a1 a1 a1
b3b2
b4
b1
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
Infinite postponing is avoided if every cycle contains at leastone fully expanded state ⇒ cycle proviso.
Cycle with Fully Expanded State
b1 b2 b3
b1 b2 b3
a1
b4
b4
a1 a1 a1
SOFSEM 2015, January 28th 41/68
Partial Order Reduction (POR)
POR Principle
To detect the cycle, depth-first search stack is used in thestandard sequential approach.
Cycle with Fully Expanded State
b1 b2 b3
b1 b2 b3
a1
b4
b4
a1 a1 a1
SOFSEM 2015, January 28th 41/68
Parallel Cycle Proviso
ProblemHow to combine POR with DM?Ample sets are computed locally, that is fine.Parallel cycle proviso is needed.
Previous known solutions and their drawbacksMimicking serial algorithms is inefficient.Full expansion at cross transitions gives small or noreduction.Sophisticated solutions with good reduction havenon-linear time complexity.
SOFSEM 2015, January 28th 42/68
Parallel Cycle Proviso
Topological Sort ProvisoNew algorithm to mark states on all cycles.No complexity increase.Achieves good reduction.Compatible with parallel processing.
SOFSEM 2015, January 28th 43/68
Topological Sort Proviso Demo
Suppose a directed graph..
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
First, indegree is computed for every vertex..
131
2 2
22
0 1
3
2
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Vertices with zero indegree are recursively “eliminated”..
131
2 2
2
3
1
0
2
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Vertices with zero indegree are recursively “eliminated”..
131
2 2
1
2
1
2
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Vertices whose indegree decreased, are marked and removed..
0 0
0
131
2 2 2
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
131
111
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
0
131
11
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
0
0 1
1
2
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
1
0
1
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
11
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
10
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
Repeat until all of the graph is processed..
0
SOFSEM 2015, January 28th 44/68
Topological Sort Proviso Demo
All cycles are covered..
SOFSEM 2015, January 28th 44/68
State Space Generation with POR
ProcedureState space graph is generated using Ample sets.Topological sort proviso is applied.Marked states are (fully) re-expanded.
Re-expansion problem & solutionAfter re-expansion new parts of the graph becomereachable.The new parts are explored the same way.Repeated until no new parts discovered.
SOFSEM 2015, January 28th 45/68
State Space Generation with POR – Demo
Generation starts from an initial state..
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Initial part of the state space is generated using transitions inAmple sets only.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Topological sort proviso is applied to mark at least one stateon every cycle.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Topological sort proviso is applied to mark at least one stateon every cycle.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Marked states are fully re-expanded..
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
New states are discovered outside the previously generatedpart of the state space.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
New part of the reduced state space is generated usingtransitions in Ample sets.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Topological sort proviso is applied to mark at least one stateon every cycle.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Marked states are fully re-expanded..
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
New state is discovered outside the previously generated partsof the state space.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Additional part of the reduced state space is generated usingtransitions in Ample sets.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Topological sort proviso is applied to mark at least one stateon every cycle.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
Marked states are fully re-expanded..
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
No new states are generated, hence the reduced state spacehas been fully constructed.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
All cycles within individual parts contain at least one fullyexpanded state.
SOFSEM 2015, January 28th 46/68
State Space Generation with POR – Demo
As well as all cycles crossing boundaries of individual parts..
SOFSEM 2015, January 28th 46/68
Parallel LTL Model Checking
LTL model checking & the new provisoThe order of the first visits to the states done by the LTLmodel checking algorithm must follow the order dictatedby the new POR reduction scheme.
SOFSEM 2015, January 28th 47/68
Experimental Evaluation
Implemented in our parallel model checker, DIVINE.
http://divine.fi.muni.cz
SOFSEM 2015, January 28th 48/68
Achieved Reduction – LTL Model Checking
Number of states stored
Model No POR DFS-POR TOP-PORpet.1 pr2 22 816 17 481 76.6% 17 098 74.9%pet.2 pr2 234 376 214 441 91.4% 210 287 89.7%pet.1 pr3 24 985 15 907 63.6% 15 479 61.9%pet.2 pr3 249 368 212 181 85.0% 202 829 81.3%mcs.1 pr2 12 206 11 545 94.5% 12 132 99.3%mcs.2 pr2 2 462 1 849 75.1% 2 370 96.2%mcs.1 pr3 15 815 14 687 92.8% 15 610 98.7%mcs.2 pr3 2 811 1 941 69.0% 2 672 95.0%synapse.1 pr2 7 226 6 758 93.5% 6 780 93.8%synapse.2 pr2 15 713 15 713 100.0% 15 713 100.0%lead_f.1 pr2 4 966 4 966 100.0% 4 966 100.0%lead_f.2 pr2 28 804 23 239 80.6% 23 239 80.6%lead_f.3 pr2 91 093 91 093 100.0% 91 093 100.0%IN TOTAL 712 641 631 801 88.7% 620 268 87.0%
SOFSEM 2015, January 28th 49/68
Outline
Need for VerificationModel CheckingParallel and DistributedLLVM-Based VerificationControl-Explicit Data-Symbolic ApproachConclusions
SOFSEM 2015, January 28th 50/68
Situation in 2012
Naive Academic AssumptionsAfter almost three decades of development, modelchecking is still not used in practice because of thestate-space explosion problem.But state-space explosion problem has been “solved”.It remains to find an industrial partner to apply thedistributed-memory model checking approach to realindustrial use-cases.
And guess what ...
... it is not so easy.
SOFSEM 2015, January 28th 51/68
Situation in 2012
Naive Academic AssumptionsAfter almost three decades of development, modelchecking is still not used in practice because of thestate-space explosion problem.But state-space explosion problem has been “solved”.It remains to find an industrial partner to apply thedistributed-memory model checking approach to realindustrial use-cases.
And guess what ...... it is not so easy.
SOFSEM 2015, January 28th 51/68
What is The Problem
Real Problems of ApplicabilityHigh costs of modelling.Manual abstractions needed.Disconnection of models from source codes.Model-based development employs structure models only(no behavioural models).
Model Checking in IndustryIndustry in general is disappointed with formal methods asformal methods promised a lot, but delivered so few.Used only by commercially successful giant companies.
SOFSEM 2015, January 28th 52/68
Model Checking for Everybody
The New GoalTarget middle-sized and small development groups.Make students use model checking in their projects.
The Big QuestionWhat would help to spread formal methods in general SWdevelopment practice given the uncertain results due tostate space explosion problem?
Necessary RequirementsSimplicity.Deployment cost equal to testing.No other manual activities.Valid use case (motivation).
SOFSEM 2015, January 28th 53/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 54/68
Model Checking Scheme
Requirements
Specification
Property
System
System Model
Model Checking
Simulation
CounterexampleInvalid
Valid
ErrorModelingFormalization
SOFSEM 2015, January 28th 54/68
Model Checking Source Code
Towards The New GoalGet rid of modelling.Direct model checking of source code files.
Our ApproachIntegrate model checking and compilation process.Build on top of intermediate representation of a compiler.Employs LLVM infrastructure.
Sigh of DespairA lot of technical work that is not very good forpublishing at theoretical conferences.
SOFSEM 2015, January 28th 55/68
LLVM Model Checking Work-Flow
1) Alternatively, GCC + DragonEgg
SOFSEM 2015, January 28th 56/68
Pros and Cons of the Approach
ProsNo restriction on programming style.Tight proximity of what is verified and what is run.Any programming language that can be compiled intoLLVM IR, can be potentially verified.
ConsCannot use external libraries until provided with thesource code.Program must be closed (all inputs given).Testing rather than verification.
SOFSEM 2015, January 28th 57/68
Use Case for LLVM-Based Model Checking
Unit Testing Multi-Threaded CodeRegular testing is insufficient (cannot control scheduling).Bugs exhibit non-deterministically.Race conditions.
Other Subjects to Model CheckingBehaviour after non-deterministic failures (e.g. malloc).Exception handling in general.
SOFSEM 2015, January 28th 58/68
LLVM-Based Model Checking
Bugs DiscoveredA couple of bugs in PDCLib.Potential memory leak in C++-11 threading.Bugs in our own code.
Other Technical Material To Talk AboutScheduling at level of individual assembler instructions.Fine-grained nature of LLVM bitcode and τ -reduction.Complete coverage of LLVM bitcode instructions.Exception handling.Virtual file system.External libraries (PThreads, PDCLib, ...).
SOFSEM 2015, January 28th 59/68
Outline
Need for VerificationModel CheckingParallel and DistributedLLVM-Based VerificationControl-Explicit Data-Symbolic ApproachConclusions
SOFSEM 2015, January 28th 60/68
Back to Verification
ObservationIn LLVM-based approach we degraded to testing.Reason: Closed programs.
Back to VerificationPromoting to verification requires the approach to be ableto handle open programs, i.e. programs that take inputs.
SOFSEM 2015, January 28th 61/68
Types of Non-Determinism
Control-FlowP1 | Q1
P2 | Q1 P1 | Q2
P1
P2
Q1
Q2
DataP1, x
P2, x´
input x
P1, −
P2, 0 P2, dom(x)
. . .
. . .P2, 1
SOFSEM 2015, January 28th 62/68
Control-Explicit Data-Symbolic Approach
ObservationNaive closure (feed with all concrete values) is inefficient.Symbolic representation of set of input values.
Set-Based Reduction (CEDS Approach)P1, x
P2, x´
input x
P1, −
P2, 0 P2, dom(x)
. . .
. . .P2, 1
SOFSEM 2015, January 28th 63/68
Control-Explicit Data-Symbolic Approach
ObservationNaive closure (feed with all concrete values) is inefficient.Symbolic representation of set of input values.
Set-Based Reduction (CEDS Approach)P1, x
P2, x´
input x
P1, −
P2, { 0, 1, ... , dom(x) }
SOFSEM 2015, January 28th 63/68
Issues in CEDS Model Checking
Complex State ManipulationEvaluating branching points.
P1, {0, ..., dom(x)} P1, {0, ..., dom(x)}
P2, ??? P3, ???
if (x>4)
then P2
else P3
x<=4x>4
P3, {0, ..., 4}P2, {5, ..., dom(x)}
May end-up as an unfeasible path.
LTL Model CheckingRequires cycle detection.Equality of CEDS states.
SOFSEM 2015, January 28th 64/68
Representing Data Efficiently
Enumerated SetsAs bad as naive closure.
BDDsGood for programs with limited data manipulation.Cannot handle multiplication.
SMT FormulaeWorst in theory, best in practice.Practical and theoretical undecidability.Employs SMT solvers (Z3).
SOFSEM 2015, January 28th 65/68
Divergence from LLVM-Based Model Checking
Fundamental ProblemHow to efficiently represent and manipulate multiple,input-value-dependent heap configurations in theset-based approach.
DivergenceComplete coverage of LLVM IR for concrete data values.Set-based represented data values, but programs with nousage of dynamic memory.
SOFSEM 2015, January 28th 66/68
Outline
Need for VerificationModel CheckingParallel and DistributedLLVM-Based VerificationControl-Explicit Data-Symbolic ApproachConclusions
SOFSEM 2015, January 28th 67/68
Quo Vadis Explicit-State Model Checking
SummaryIs there a hope for explicit-state model checking?Unit testing of mutli-threaded code is a perfectlyvalid use case.Contemporary HW architectures offer tremendouscomputing power, for unit testing by model checking,state space explosion can be reasonable well fought.CEDS Approach makes it competitive to other formalverification approaches.
Got Interested?http://divine.fi.muni.cz
Thank You for Your Attention
SOFSEM 2015, January 28th 68/68
Quo Vadis Explicit-State Model Checking
SummaryIs there a hope for explicit-state model checking?Unit testing of mutli-threaded code is a perfectlyvalid use case.Contemporary HW architectures offer tremendouscomputing power, for unit testing by model checking,state space explosion can be reasonable well fought.CEDS Approach makes it competitive to other formalverification approaches.
Got Interested?http://divine.fi.muni.cz
Thank You for Your AttentionSOFSEM 2015, January 28th 68/68