Partial Order Reduction: Main Idea

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Automatic Verification Book: Chapter 6. How can we check the model? The model is a graph. The specification should refer the the graph representation.
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Tutorial I – An Introduction to Model Checking Peng WU INRIA Futurs LIX, École Polytechnique.
CS 267: Automated Verification Lecture 2: Linear vs. Branching time. Temporal Logics: CTL, CTL*. CTL model checking algorithm. Counter-example generation.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
ECE Synthesis & Verification - L271 ECE 697B (667) Spring 2006 Synthesis and Verification of Digital Systems Model Checking basics.
PROTOCOL VERIFICATION & PROTOCOL VALIDATION. Protocol Verification Communication Protocols should be checked for correctness, robustness and performance,
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
CS6133 Software Specification and Verification
UPPAAL Introduction Chien-Liang Chen.
Hybrid Systems Presented by: Arnab De Anand S. An Intuitive Introduction to Hybrid Systems Discrete program with an analog environment. What does it mean?
1 Partial Order Reduction. 2 Basic idea P1P1 P2P2 P3P3 a1a1 a2a2 a3a3 a1a1 a1a1 a2a2 a2a2 a2a2 a2a2 a3a3 a3a3 a3a3 a3a3 a1a1 a1a1 3 independent processes.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
Efficient Reachability Analysis for Verification of Asynchronous Systems Nishant Sinha.
CS 267: Automated Verification Lecture 10: Nested Depth First Search, Counter- Example Generation Revisited, Bit-State Hashing, On-The-Fly Model Checking.
PSWLAB S PIN Search Algorithm from “THE SPIN MODEL CHECKER” by G Holzmann Presented by Hong,Shin 9 th Nov SPIN Search Algorithm.
1 Temporal Claims A temporal claim is defined in Promela by the syntax: never { … body … } never is a keyword, like proctype. The body is the same as for.
CS 267: Automated Verification Lecture 7: SMV Symbolic Model Checker, Partitioned Transition Systems, Counter-example Generation in Symbolic Model Checking.
Lecture 2: Reasoning with Distributed Programs Anish Arora CSE 6333.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
1 Carnegie Mellon UniversitySPINFlavio Lerda SPIN An explicit state model checker.
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.
Flavio Lerda 1 LTL Model Checking Flavio Lerda. 2 LTL Model Checking LTL –Subset of CTL* of the form: A f where f is a path formula LTL model checking.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
1 Carnegie Mellon UniversitySPINFlavio Lerda Bug Catching SPIN An explicit state model checker.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
CS6133 Software Specification and Verification
On Reducing the Global State Graph for Verification of Distributed Computations Vijay K. Garg, Arindam Chakraborty Parallel and Distributed Systems Laboratory.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Copyright , Doron Peled and Cesare Tinelli. These notes are based on a set of lecture notes originally developed by Doron Peled at the University.
CS 267: Automated Verification Lecture 3: Fixpoints and Temporal Properties Instructor: Tevfik Bultan.
Defining Liveness by Bowen Alpern and Fred B. Schneider Presented by Joe Melnyk.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
CS 103 Discrete Structures Lecture 13 Induction and Recursion (1)
1 Symmetry Symmetry Chapter 14 from “Model Checking” by Edmund M. Clarke Jr., Orna Grumberg, and Doron A. Peled presented by Anastasia Braginsky March.
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
CompSci 102 Discrete Math for Computer Science March 13, 2012 Prof. Rodger Slides modified from Rosen.
Variants of LTL Query Checking Hana ChocklerArie Gurfinkel Ofer Strichman IBM Research SEI Technion Technion - Israel Institute of Technology.
Presented by: Belgi Amir Seminar in Distributed Algorithms Designing correct concurrent algorithms Spring 2013.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Symbolic Model Checking of Software Nishant Sinha with Edmund Clarke, Flavio Lerda, Michael Theobald Carnegie Mellon University.
Chapter 2 1. Chapter Summary Sets (This Slide) The Language of Sets - Sec 2.1 – Lecture 8 Set Operations and Set Identities - Sec 2.2 – Lecture 9 Functions.
6/12/20161 a.a.2015/2016 Prof. Anna Labella Formal Methods in software development.
Complexity Relief Techniques for Model Checking METU, Aug SOFTWARE VERIFICATION WORKSHOP Hüsnü Yenigün Sabanci University Informatics Institute,
Complexity of Compositional Model Checking of Computation Tree Logic on Simple Structures Krishnendu Chatterjee Pallab Dasgupta P.P. Chakrabarti IWDC 2004,
Basic concepts of Model Checking
Formal methods: Lecture
Automatic Verification
ITEC452 Distributed Computing Lecture 5 Program Correctness
Formal Methods in software development
An explicit state model checker
Producing short counterexamples using “crucial events”
Abstraction.
Linear Time Properties
Scalability in Model Checking
Introduction to verification
Formal Methods in software development
Program correctness Linear Time Temporal Logic
Presentation transcript:

CS 267: Automated Verification Lecture 11: Partial Order Reduction Instructor: Tevfik Bultan

Partial Order Reduction: Main Idea Statements of concurrently executing threads can generate many different interleavings all these different interleavings are allowable behavior of the program A model checker has to check that: For all possible interleavings, the behavior of the program is correct However different interleavings may generate equivalent behaviors In such cases it is sufficient to check just one interleaving without exhausting all the possibilities This is called partial order reduction The following discussion on partial order reduction is based on the book: Model Checking by E. M. Clarke, Orna Grumberg, Doron Peled

Concurrency In Asynchronous Systems Concurrent execution of multiple threads or processes can be modeled as interleaved execution of atomic instructions Given n atomic instructions that can be executed concurrently there are n! different execution sequences If these n atomic instructions are independent, all n! execution sequences will end at the same global state However, they will generate 2n intermediate states (one for each subset of the n atomic instructions) If the property we are interested in verifying does not distinguish among the n! possible execution sequences, then we can use a single execution sequence to represent all n! of them and visit only n states instead of 2n states

An Example: Three Independent Transitions a, b, c: boolean Initial: a=b=c=false i1: a:=true || i2: b:=true || i3: c:=true Can we pick one representative execution (e.g., i2,i1,i3) rather than trying all 6 (3!) executions and visiting all 8 (23) states? When is it safe to pick only one representative execution? Can we do this on the fly without generating the whole state space? F,F,F i3 i1 i2 T,F,F F,T,F F,F,T i1 i3 i2 i2 i3 i1 F,T,T T,T,F T,F,T i2 i3 i1 T,T,T

Another Example: Partial vs. Total Order a, b, c, d: integer Initial: a=b=c=d=0 P1: P11 : a := a+1; P12 : b := b+1; Program: P1 || P2 P2: P21 : c := d+1; P22 : d := c*2; The order of execution: P11 < P12 and P21 < P22 Note that this is a partial order for P11, P12, P21, P22 Any execution sequence which obeys this partial order is a valid execution sequence An interleaved execution sequence gives a total order We want to pick one representative interleaved execution sequence and avoid generating all of them

Some Definitions Given a transition system (S, I, R) and a labeling function L: S  2AP We assume that R = t1  t2  …  tn where each ti  S  S is called a transition Let T = { t1 , t2 , … , tn } denote the set of transitions Given a transition t  T, following notations are equivalent: (s,s’)  t t(s,s’) s’=t(s) (here we are assuming that t is deterministic, i.e. for any state s, there is at most one state s’ s.t. (s,s’)  t) A transition t is enabled at state s, if there exists an s’ such that t(s,s’) holds, otherwise it is disabled enabled(s) is the set of transitions that are enabled at state s

Independence Relation The independence relation I  T  T is a symmetric, anti-reflexive relation such that, for each s  S and for each (t, t’)  I, the following conditions hold: enabledness: If t, t’  enabled(s) then t  enabled(t’(s)) Independent transitions do not disable each other (but they can enable each other) commutativity: If t, t’  enabled(s) then t(t’(s)) = t’(t(s)) Recall that: symmetric: for all t, t’  T, (t, t’)  I  (t’,t)  I anti-reflexive: for all t  T, (t, t)  I Dependence relation is defined as the complement of the independence relation

Invisible Transitions A transition t is invisible with respect to propositions AP’  AP if for each pair of states s, s’ such that s’ = t(s) L(s)  AP’ = L(s’)  AP’ i.e., execution of the transition t from any state does not change the value of the propositions in AP’ A transition is visible if it is not invisible

Stuttering Equivalence Two infinite paths x = s0, s1, s2, ... and y = r0, r1, r2, … are stuttering equivalent (denoted as x st y), if there are two infinite sequences of positive integers: 0 = i0 < i1 < i2 < … and 0 = j0 < j1 < j2 < … such that for every k  0 L(sik) = L(sik + 1) = … = L(si(k+1) -1) = L(rjk) = L(rjk + 1) = … = L(rj(k+1) -1) A property is invariant under stuttering if for each stuttering equivalent path either both satisfy the property or neither satisfy the property.

LTLX LTLX is the temporal logic LTL without the next state operator X Any LTLX formula is invariant under stuttering Two transition systems TS1 and TS2 are stuttering equivalent if they have the same initial states for each path x in TS1 that starts at the initial state s, there exists a path y in TS2 which starts from the same initial state and x st y If two transitions systems are stuttering equivalent, then they satisfy the same set of LTLX properties

Partial Order Reduction We can check LTLX properties using partial order reduction techniques While visiting a state s, instead of exploring all the transitions in enabled(s), we will just explore the transitions in ample(s) where ample(s)  enabled(s) Using ample(s) instead of enabled(s) should reduce the number of states visited, but it should not change the result of the verification, and the cost of computing ample(s) should be small.

Modified Depth First Search main() { StateSpace = {s0}; expand_state(s0); } expand_state(s) { work_set(s) := ample(s); while work_set(s) is not empty { let t  work_set(s); work_set(s) := work_set(s) – {t}; s’ := t(s); if s’  StateSpace { StateSpace := StateSpace  s’; expand_state(s’); create_edge(s, t, s’); set completed(s);

Conditions for Partial Order Reduction Now we will discuss four conditions for ample sets If the ample sets satisfy these conditions then the result of the state space search without using partial order reduction and with using partial order reduction should be the same for LTLX properties Let’s call the state graph generated with state space search without using partial order reduction the full state graph and the state graph generated with state space search with using partial order reduction the reduced state graph If the ample sets satisfy these four conditions then the full state graph and the reduced state graph are stuttering equivalent Hence, they satisfy the same set of LTLX properties

Conditions for Partial Order Reduction C0: ample(s) =  if and only if enabled(s) =  If a state has at least one successor in the full state graph, then it should also have at least one successor in the reduced state graph C1: Along every path in the full state graph that starts at s, a transition that is dependent on a transition in ample(s) cannot be executed without a transition in ample(s) occuring first This implies that the transitions in enabled(s) – ample(s) are all independent of those in ample(s) C2: If s is not fully expanded (i.e., ample(s)  enabled(s)), then every t  ample(s) is invisible C3: A cycle is not allowed if it contains a state in which some transition t is enabled but is never included in ample(s) for any state s on the cycle.

Simplest Example Basic question: Can we explore just the path s1, s2, s4 and ignore the path s1, s3, s4? If we can we can, then we will set ample(s1) = {t1} This will allow us to ignore the transition t2 at state s1 Note that ample(s1)  enabled(s1) = {t1, t2} s1 t1 t2 s2 s3 t1 t2 s4

When Can We Do It? In order to set ample(s1) = {t1} we need certain conditions to hold First we need t1 and t2 to commute t2(t1(s1)) = t1(t2(s1)) This is true in the figure t2(t1(s1)) = t1(t2(s1)) = s4 Second, we need to make sure that t2  enabled(t1(s1)) This is also true in the figure t2  enabled(t1(s1)) = enabled(s2) These two conditions basically state that the transitions that are in ample(s1) and enabled(s1) - ample(s1) should be independent which is covered by condition C1 s1 t1 t2 s2 s3 t1 t2 s4

Possible problems If we ignore the path s1, s3, s4 what can happen? Problem 1: The truth value of the property we are interested in may be different for the paths s1, s2, s4 and s1, s3, s4 Problem 2: State s3 may have other successors which may not be reachable if we do not visit s3 s1 t1 t2 s2 s3 t1 t2 s4

When Can We Do It? Condition C2 resolves Problem 1 Due to condition C2, since s1 is not fully explored, every transition in ample(s1) must be invisible This means that as far as the property of interest is concerned the paths s1, s2, s4 and s1, s3, s4 are stuttering equivalent This means that s1, s2, s4 will satisfy the property of interest if and only if s1, s3, s4 satisfies the property of interest Hence ignoring the path s1, s3, s4 will not change the result of the verification s1 t1 t2 s2 s3 t1 t2 s4

When Can We Do It? Condition C1 resolves the Problem 2 Assume that there is a state s5 reachable from state s3 with transition t3 Due to condition C1, t3 and t1 must be independent Then, t3 is enabled in s4 Since t3 and t1 are independent we also have t3(t1(s3)) = t1(t3(s3)) Since t1 is invisible the following paths are stuttering equivalent: s1, s2, s4, s6 and s1, s3, s5 s1 t1 t2 s2 s3 t3 t1 t2 s4 s5 t3 s6 t1

What about condition C3? Assume that: Process 1 Process 2 Assume that: y is independent of t1, t2 and t3 t1, t2 and t3 are interdependent y is visible t1, t2 and t3 are invisible t1 t3 y t2 Full state graph s1 t1 t3 t2 s3 s2 y y y s4 t3 t1 t2 s6 s5

What about condition C3? If we ignore condition C3 we can do the following: ample(s1) = {t1} ample(s2) = {t2} ample(s3) = {t3} Each state defers the execution of y to a future state. When the cycle is closed the depth first search terminates (since the only successor is already visited) Transition y is never executed although it is visible! Condition C3 prevents this scenario Reduced state graph s1 t1 t3 t2 s3 s2 This reduction is not sound since we ignored a visible transition: y