quo vadis explicit-state model checking

Post on 01-Feb-2017

216 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

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

top related