Infinite State Model Checking with Presburger Arithmetic Constraints - PowerPoint PPT Presentation

Loading...

PPT – Infinite State Model Checking with Presburger Arithmetic Constraints PowerPoint presentation | free to download - id: 6d0846-YzY0M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Infinite State Model Checking with Presburger Arithmetic Constraints

Description:

Infinite State Model Checking with Presburger Arithmetic Constraints Tevfik Bultan Department of Computer Science University of California, Santa Barbara – PowerPoint PPT presentation

Number of Views:5
Avg rating:3.0/5.0
Slides: 102
Provided by: Valued236
Learn more at: http://www.cs.ucsb.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Infinite State Model Checking with Presburger Arithmetic Constraints


1
Infinite State Model Checking with Presburger
Arithmetic Constraints
  • Tevfik Bultan
  • Department of Computer Science
  • University of California, Santa Barbara

2
Joint Work with My Students
  • Action Language Verifier
  • Tuba Yavuz-Kahveci (PhD 2004)
  • Constantinos Bartzis (PhD 2004)
  • Design for verification
  • Aysu Betin-Can (PhD 2005)

3
Infinite State Model Checking?
  • Model checking started as a finite state
    verification technique
  • Advantages of finite state systems
  • Exhaustive state enumeration is possible for
    finite state systems
  • Disadvantages of infinite state systems
  • Verification problems that are computable for
    finite state systems are uncomputable for
    infinite state systems

4
Why Care About Infinity?
  • Computer systems do not have infinite memory or
    infinite time
  • So why care about infinity?
  • Infinity is an abstraction
  • Abstraction is at the core of computer science
  • Computers are built with layers of abstractions
  • Abstraction is necessary for design
  • Abstraction is necessary for analysis

5
Why Care About Infinity?
  • Reason 1
  • Enables us to check a specification with respect
    to an arbitrarily large number of components or
    memory
  • For example, arbitrary number of threads
  • Reason 2
  • Rather than developing verification techniques
    that rely on the bound of the state space to
    terminate
  • Enables us to develop infinite state verification
    techniques that terminate independent of the
    bound
  • A technique which is guaranteed to terminate is
    not helpful if it runs out of memory

6
An Example
  • A simple example that demonstrates limitations of
    (finite state) model checkers
  • Property P can be verified with an infinite state
    model checker that uses standard backward
    fixpoint computations
  • Fixpoint computation for some properties
  • for example, AG(State1 ? x ?6)
  • may not converge but we can use conservative
    approximations

xx1
State0
State1
xx1
Initial x0 ? State0
P AG(State1 ? x is odd)
P AG(State1 ? (?? . x 2?1))
7
Outline
  • Model checking with arithmetic constraints
  • Conservative approximations
  • Automata representation for arithmetic
    constraints
  • Composite representation
  • Action Language Verifier (ALV)
  • Checking synchronization in concurrent programs
    with ALV

8
Symbolic Model Checking McMillan et al. LICS
1990
  • Represent sets of states and the transition
    relation as Boolean logic formulas
  • Forward and backward fixpoints can be computed by
    iteratively manipulating these formulas
  • Forward, backward image Existential variable
    elimination
  • Conjunction (intersection), disjunction (union)
    and negation (set difference), and equivalence
    check
  • Use an efficient data structure for manipulation
    of Boolean logic formulas
  • BDDs

9
Symbolic Model Checking
  • What do you need to compute fixpoints?
  • Symbolic Conjunction(Symbolic,Symbolic)
  • Symbolic Disjunction(Symbolic,Symbolic)
  • Symbolic Negation(Symbolic)
  • Boolean EquivalenceCheck(Symbolic,Symbolic)
  • Symbolic Precondition(Symbolic)
  • Precondition (i.e., EX) computation is handled
    by
  • variable renaming, followed by conjunction,
    followed by existential variable elimination
  • Infinite state model checking Use a symbolic
    representation that is capable of representing
    infinite sets and supports the above functionality

10
Linear Arithmetic Constraints
  • Linear arithmetic formulas can represent
    (infinite) sets of valuations of unbounded
    integers
  • Linear integer arithmetic formulas on can be
    stored as a set of polyhedra
  • where each is a linear equality or
    inequality constraint
  • and each is a polyhedron
  • xi integer variable, ai coefficient, c constant

11
A Linear Arithmetic Constraint Manipulator
  • Omega Library Pugh et al.
  • A tool for manipulating Presburger arithmetic
    formulas First order theory of integers without
    multiplication
  • Equality and inequality constraints are not
    enough
  • Divisibility constraints are also needed
  • which means is divisible by

12
Integers are Complicated
y
x 5 ? 2y
2y ? x 1
x ? 3y
3y ? x 7
29
3
x
dark shadow
real shadow
13
Presburger Arithmetic Model Checking Bultan et
al. CAV97, TOPLAS99
  • Use linear arithmetic constraints as a symbolic
    representation
  • Use a Presburger arithmetic manipulator as the
    symbolic engine (Omega library)
  • Compute fixpoints to verify or falsify CTL
    properties
  • Use conservative approximations to achieve
    convergence

14
What About Using BDDs for Encoding Arithmetic
Constraints?
  • Arithmetic constraints on bounded integer
    variables can be represented using BDDs
  • Use a binary encoding
  • represent integer x as x0x1x2... xk
  • where x0, x1, x2, ... , xk are binary variables
  • You have to be careful about the variable
    ordering!
  • BDDs and constraint representations are both
    applicable
  • Which one is better?

15
Arithmetic Constraints vs. BDDs Bultan TACAS00
16
Arithmetic Constraints vs. BDDs
17
Arithmetic Constraints vs. BDDs
  • Constraint based verification can be more
    efficient than BDDs for integers with large
    domains
  • Constraint based verification can be used to
    automatically verify infinite state systems
  • cannot be done using BDDs
  • However, BDD-based verification is more robust
    and the arithmetic constraint representation has
    two problems
  • Problem 1 Constraint based verification does not
    scale well when there are boolean or enumerated
    variables in the specification
  • Problem 2 Price of infinity
  • CTL model checking becomes undecidable for
    infinite domains

18
Outline
  • Model checking with arithmetic constraints
  • Conservative approximations
  • Automata representation for arithmetic
    constraints
  • Composite representation
  • Action Language Verifier (ALV)
  • Checking synchronization in concurrent programs
    with ALV

19
Conservative Approximations
  • Compute a lower ( p? ) or an upper ( p )
    approximation to the truth set of the property (
    p )

20
Conservative Approximations
  • Compute a lower ( p? ) or an upper ( p )
    approximation to the truth set of the property (
    p )
  • There are three possible outcomes

p
p?
I
1) The property is satisfied
21
Conservative Approximations
  • Compute a lower ( p? ) or an upper ( p )
    approximation to the truth set of the property (
    p )
  • There are three possible outcomes

I
p
p?
p
I
p?
1) The property is satisfied
3) I dont know
sates which violate the property
I
p
? p?
p
2) The property is false and here is a
counter-example
22
Conservative Approximations
  • Compute a lower ( p? ) or an upper ( p )
    approximation to the truth set of the property (
    p )
  • There are three possible outcomes

I
p
p?
p
I
p?
1) The property is satisfied
3) I dont know
sates which violate the property
I
p
? p?
p
2) The property is false and here is a
counter-example
23
Conservative Approximations
  • Truncated fixpoint computations
  • To compute a lower bound for a least-fixpoint
    computation
  • Stop after a fixed number of iterations
  • Widening
  • To compute an upper bound for the least-fixpoint
    computation
  • We use a generalization of the polyhedra widening
    operator by Cousot and Halbwachs POPL78

24
Polyhedra Widening
y
x ? y
y ? 5
1 ? y
x
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y
25
Polyhedra Widening
x ? y
y
x ? y
y ? 5
y ? 5
1 ? y
1 ? y
x
x ? 5
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y Ai1 x ? y ?
x ? 5 ? y ? 5 ? 1 ? y
26
Polyhedra Widening
y
x ? y
y ? 5
1 ? y
x
x ? 5
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y Ai1 x ? y ?
x ? 5 ? y ? 5 ? 1 ? y Ai?Ai1 x ? y ? y ? 5 ?
1 ? y
27
Polyhedra Widening
x ? y
y
x ? y
y ? 5
y ? 5
1 ? y
1 ? y
x
x ? 5
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y Ai1 x ? y ?
x ? 5 ? y ? 5 ? 1 ? y Ai?Ai1 x ? y ? y ? 5 ?
1 ? y
Ai ? Ai1 is defined as all the constraints in
Ai that are also satisfied by Ai1
28
Outline
  • Model checking with arithmetic constraints
  • Conservative approximations
  • Automata representation for arithmetic
    constraints
  • Composite representation
  • Action Language Verifier (ALV)
  • Checking synchronization in concurrent programs
    with ALV

29
Automata Representation for Arithmetic
Constraints Bartzis, Bultan CIAA02, IJFCS 02
  • Given an atomic linear arithmetic constraint in
    one of the following two forms
  • we can construct an FA which accepts all the
    solutions to the given constraint
  • By combining such automata one can handle full
    Presburger arithmetic

30
Basic Construction
  • We first construct a basic state machine which
  • Reads one bit of each variable at each step,
    starting from the least significant bits
  • and executes bitwise binary addition and stores
    the carry in each step in its state

In my figures alphabet symbols are written
vertically!
0 1 0 0 / / 0 1
0 1 / 1
0 1 1 1 / / 0 1
1 0 / 0
Example x 2y
1 1 / 1
0 1 / 0
1 1 / 0
010 2 ? 001
0 1 0 0 / / 0 1
0 0 / 1
1
0
0
Number of states
31
Automaton Construction
  • Equality With 0
  • All transitions writing 1 go to a sink state
  • State labeled 0 is the only accepting state
  • For disequations (?), state labeled 0 is the only
    rejecting state
  • Inequality (lt0)
  • States with negative carries are accepting
  • No sink state
  • Non-zero Constant Term c
  • Same as before, but now -c is the initial state
  • If there is no such state, create one (and
    possibly some intermediate states which can
    increase the size by c)

32
Conjunction and Disjunction
  • Conjunction and disjunction is handled by
    generating the product automaton

33
Other Extensions
  • Existential quantification (necessary for pre and
    post)
  • Project the quantified variables away
  • The resulting FA is non-deterministic
  • Determinization may result in exponential blowup
    of the FA size but we do not observe this in
    practice
  • For universal quantification use negation
  • Constraints on all integers
  • Use 2s complement arithmetic
  • The basic construction is the same
  • In the worst case the size doubles

34
Experiments
  • We implemented these algorithms using MONA
    Klarlund et al
  • We integrated them to our infinite state model
    checker
  • We compared our automata representation against
  • the polyhedral representation used in the Omega
    library
  • the automata representation used in LASH
    Boigelot and Wolper
  • we also integrated LASH to our model checker by
    writing a wrapper around it

35
Experimental results
36
Experimental results
37
Experimental results
38
Efficient Pre- and Post-condition Computations
Bartzis, Bultan CAV03
  • Pre and post condition computations can cause an
    exponential blow-up in the size of the automaton
    in the worst case
  • We do not observe this blow-up in the experiments
  • We proved that for a common class of systems this
    blow up does not occur

39
Assumptions About the Transition Relation
  • We assume that the transition relation of the
    input system is a disjunction of formulas in the
    following form
  • guard(R) ? update(R)
  • where
  • guard(R) is a Presburger formula on current state
    variables and
  • update(R) is of the form
  • xif(x1, , xv) ? ? xj xj
  • In asynchronous concurrent systems the transition
    relation is usually in the above form

j?i
40
Three Classes of Updates
  • xi c
  • xi xi c
  • xi ?j1aj xj c
  • We proved that
  • Computation of pre is polynomial for all 3 cases
  • Computation of post is polynomial for 2 and for
    3, whenever ai is odd.

v
41
Other Results Related to Automata
Encoding Bartzis, Bultan TACAS03, STTT
  • We developed efficient BDD construction
    algorithms and proved bounds for the sizes of the
    BDDs for bounded linear arithmetic constraints
  • Given a linear arithmetic formula that contains n
    atomic constraints on v bounded integer variables
    represented with b-bits, the size of the BDD is
  • These results explain why all three versions of
    SMV (NuSMV, CMU SMV and Cadence SMV) are
    inefficient in handling linear arithmetic
    constraints
  • In SMV the BDD size could be exponential in b

42
Other Results Related to Automata
Encoding CAV04
  • We defined a widening operator for the automata
    representation of arithmetic constraints
  • The widening operator looks for similar states in
    two consecutive iterations (Ai and Ai1) and
    creates an equivalence relation
  • then it merges the states in the same equivalence
    class
  • We can prove that for some cases this widening
    operator computes the exact fixpoint
  • for example for updates of the form xxc

43
Example
module incr_1 integer y parameterized
integer x initial yx incr_1 y'y1
spec AG(ygtx) endmodule
  • The sequence yx, yx ? yx1, yx ? yx1 ?
    yx2, does not converge
  • However we know that a fixpoint exists (y?x) and
    is representable as an arithmetic constraint

44
Widening
  • Instead of computing a sequence A1, A2, where
  • Ai1Ai?post(Ai)
  • compute A1, A2, where
  • Ai1Ai?(Ai?post(Ai))
  • By definition A?B ? A?B
  • The goal is to find a widening operator ? such
    that
  • The sequence A1, A2, converges
  • It converges fast
  • The computed fixpoint is as close as possible to
    the exact set of reachable states

45
Widening Arithmetic Automata
  • Given automata A and A we want to compute A?A
  • We say that states k and k are equivalent (k?k)
    if either
  • k and k can be reached from either initial state
    with the same string (unless k or k is a sink
    state)
  • or, the languages accepted from k and k are
    equal
  • or, for some state k, k?k and k?k
  • The states of A?A are the equivalence classes of
    ?

46
Example
0 1 0,1
X X
yx
1 0 0,1






0
0
1
0
1
1
3
0 1 0,1
yx ? yx1
0
1 0 0,1
0 X 0,1
1
1
X X
0
3
0 1
2
1 0
2
0 1 0,1
3
1 0
47
Example
0 1 0,1
0 1 0,1
X X
1 0 0,1
0 X 0,1
1
X X
1 0 0,1
0
1
0
3
0 1
1 0
2
0 1 0,1
1 0
0 X 0,1
1 0
X X

1 0
0 1 0,1
0,1
2
3
0 1
48
Example
0 0,
1 0
X X
X 1
1 0
0 1 0,1








2
0
0
0
1
2
0 1
1
1
3
2
4
0 X 0,1
0
1 0
X X
X 1
1 0
0 0
2
1
0 1 0,1
0
3
4
0 1
0 1
2
3
1 0
1 0
1
4
X 0
49
Example
0 X 0,1
1 0
X X
0 0,
1 0
X X
X 1
X 1
1 0
0 0
2
0 1 0,1
1 0
0 1 0,1
0
1
2
0
3
4
0 1
0 1
0 1
1 0
1 0
1
X 0
0 X 0,1
X 1 0,0
1 0

Represents y?x
0,2
1,3
0 1
50
Outline
  • Model checking with arithmetic constraints
  • Conservative approximations
  • Automata representation for arithmetic
    constraints
  • Composite representation
  • Action Language Verifier (ALV)
  • Checking synchronization in concurrent programs
    with ALV

51
Composite Model Checking Bultan, Gerber, League
ISSTA 98, TOSEM 00
  • Map each variable type to a symbolic
    representation
  • Map boolean and enumerated types to BDD
    representation
  • Map integer type to a linear arithmetic
    constraint representation
  • Use a disjunctive representation to combine
    different symbolic representations composite
    representation
  • Each disjunct is a conjunction of formulas
    represented by different symbolic representations
  • we call each disjunct a composite atom

52
Composite Representation
composite atom
symbolic rep. 1
symbolic rep. 2
symbolic rep. t
Example x integer, y boolean xgt0 and x?x-1
and y or xlt0 and x?x and y?y
arithmetic constraint representation
arithmetic constraint representation
BDD
BDD
53
Composite Symbolic Library Yavuz-Kahveci,
Tuncer, Bultan TACAS01, Yavuz-Kahveci, Bultan
FroCos 02, STTT 03
  • Uses a common interface for each symbolic
    representation
  • Easy to extend with new symbolic representations
  • Enables polymorphic verification
  • Multiple symbolic representations
  • As a BDD library we use Colorado University
    Decision Diagram Package (CUDD) Somenzi et al
  • As an integer constraint manipulator we use Omega
    Library Pugh et al

54
Composite Symbolic Library Class Diagram
Symbolic
  • intersect()
  • union()
  • complement()
  • isSatisfiable()
  • isSubset()
  • pre()
  • post()

CUDD Library
OMEGA Library
55
Pre and Post-condition Computation
  • Variables
  • x integer, y boolean
  • Transition relation
  • R xgt0 and x?x-1 and y or xlt0 and x?x and
    y?y
  • Set of states
  • s x2 and !y or x0 and !y
  • Compute post(s,R)

56
Pre and Post-condition Distribute
  • R xgt0 and x?x-1 and y or xlt0 and x?x and
    y?y
  • s x2 and !y or x0 and y
  • post(s,R) post(x2 , xgt0 and x?x-1) ? post(!y
    , y)
  • x1 y
  • post(x2 , xlt0 and x?x) ? post (!y , y?y)
  • false
    !y
  • post(x0 , xgt0 and x?x-1) ? post(y , y)
  • false
    y
  • post (x0 , xlt0 and x?x) ? post (y, y?y )
  • x0
    y
  • x1 and y or x0 and y

57
Polymorphic Verifier
  • Symbolic TranSyscheck(Node f)
  • Symbolic s check(f.left)
  • case EX
  • s.pre(transRelation)
  • case EF
  • do
  • sold s
  • s.pre(transRelation)
  • s.union(sold)
  • while not sold.isEqual(s)

? Action Language Verifier is polymorphic ? It
becomes a BDD based model checker when there or
no integer variables
58
Composite Representation Shape
Graphs Yavuz-Kahveci, Bultan SAS 02
  • Shape graphs represent the states of the heap
  • Each node in the shape graph represents a
    dynamically allocated memory location
  • Heap variables point to nodes of the shape graph
  • The edges between the nodes show the locations
    pointed by the fields of the nodes

heap variables add and top point to node
n1 add.next is node n2 top.next is also node
n2 add.next.next is null
add
top
next
n1
n2
next
59
Composite Symbolic Library Further Extended
Symbolic
  • union()
  • isSatisfiable()
  • isSubset()
  • forwardImage()

BoolSym
HeapSym
IntSym
representation BDD
representation list of ShapeGraph
representation list of Polyhedra
  • union()
  • union()
  • union()

CUDD Library
OMEGA Library
60
Forward Fixpoint
arithmetic constraint representation
A set of shape graphs
BDD
add
top
?
?
pcl1 ? mutex
numItems2
61
Post-condition Computation Example
add
top
?
?
set of states
pcl4 ? ?mutex
numItems2
?
transition relation
pcl4 and mutex pcl1
?
numItemsnumItems1
?
pcl1 ? mutex
numItems3
62
Again Fixpoints Do Not Converge
  • We have two reasons for non-termination
  • integer variables can increase without a bound
  • the number of nodes in the shape graphs can
    increase without a bound
  • As I mentioned earlier, we use widening on
    integer variables to achieve convergence
  • For heap variables we use the summarization
    operation

63
Summarization Example
add
top
?
?
pcl1 ? mutex
numItems3
summarized nodes
After summarization, it becomes
add
top
?
?
pcl1 ? mutex
numItems3 ? summarycount2
a new integer variable representing the number of
concrete nodes encoded by the summary node
summary node
64
Simplification
add
top
numItems3 ? summaryCount2
?
?
pcl1 ? mutex
?
add
top
?
numItems4 ? summaryCount3
?

pcl1 ? mutex

add
top
?
  • (numItems4
  • summaryCount3
  • numItems3
  • ? summarycount2)

?

pcl1 ? mutex
65
Simplification On the Integer Part
add
  • (numItems4
  • summaryCount3
  • numItems3
  • ? summaryCount2)

top
?
?

pcl1 ? mutex

add
top
?
?
  • numItemssummaryCount1
  • 3 ? numItems
  • numItems ? 4

pcl1 ? mutex

66
Then We Use Integer Widening
add
top
?
?
  • numItemssummaryCount1
  • 3 ? numItems
  • numItems ? 4


pcl1 ? mutex
?
add
?
?
top
  • numItemssummaryCount1
  • 3 ? numItems
  • numItems ? 5


pcl1 ? mutex

add
top
?
?
  • numItemssummaryCount1
  • 3 ? numItems

pcl1 ? mutex

Now, fixpoint converges
67
Verified Properties
Specification Verified Invariants
Stack topnull ? numItems0
top?null ? numItems?0
numItems2 ? top.next?null
Single Lock Queue headnull ? numItems0
head?null ? numItems?0
(headtail ? head ?null) ? numItems1
head?tail ? numItems?0
Two Lock Queue numItemsgt1 ? head?tail
numItemsgt2 ? head.next?tail
68
Verifying Linked Lists with Multiple Fields
  • Pattern-based summarization
  • User provides a graph grammar rule to describe
    the summarization pattern
  • L x next x y, prev y x, L y
  • Represent any maximal sub-graph that matches the
    pattern with a summary node
  • no node in the sub-graph pointed by a heap
    variable

69
Summarization Pattern Examples
...
n
n
n
L x ? x.n y, L y
...
n
n
n
L x ? x.n y, y.p x, L y
p
p
p
...
n
n
n
L x ? x.n y, x.d z, L y
d
d
d
70
Outline
  • Model checking with arithmetic constraints
  • Conservative approximations
  • Automata representation for arithmetic
    constraints
  • Composite representation
  • Action Language Verifier (ALV)
  • Checking synchronization in concurrent programs
    with ALV

71
Action Language Tool Set
Action Language Specification
Action Language Parser
Composite Symbolic Library
Omega Library
CUDD Package
MONA
Verified
Counter example
Presburger Arithmetic Manipulator
BDD Manipulator
Automata Manipulator
72
Action Language Bultan, ICSE 00, Bultan,
Yavuz-Kahveci, ASE 01
  • Variables boolean, enumerated, integer
    (unbounded)
  • Parameterized constants
  • specifications are verified for all possible
    values
  • Transition relation is defined using actions and
    modules
  • Atomic actions Predicates on current and next
    state variables
  • Action composition
  • asynchronous () or synchronous ()
  • A module is defined as asynchronous and/or
    synchronous compositions of its actions and
    submodules

73
Readers Writers Example A Closer Look
S Cartesian product of variable domains
defines the set of states
  • module main()
  • integer nr
  • boolean busy
  • restrict nrgt0
  • initial nr0 and !busy
  • module Reader()
  • boolean reading
  • initial !reading
  • rEnter !reading and !busy and
  • nrnr1 and reading
  • rExit reading and !reading and nrnr-1
  • Reader rEnter rExit
  • endmodule
  • module Writer()
  • ...
  • endmodule

I Predicates defining the initial states
R Atomic actions of the Reader
R Transition relation of Reader defined as
asynchronous composition of its atomic actions
R Transition relation of main defined as
asynchronous composition of two Reader and two
Writer processes
74
Arbitrary Number of Threads
  • Counting abstraction
  • Create an integer variable for each local state
    of a thread
  • Each variable will count the number of threads in
    a particular state
  • Local states of the threads have to be finite
  • Specify only the thread behavior that relates to
    the correctness of the controller
  • Shared variables of the controller can be
    unbounded
  • Counting abstraction can be automated

75
Readers-Writers After Counting Abstraction
Parameterized constants introduced by the
counting abstractions
  • module main()
  • integer nr
  • boolean busy
  • parameterized integer numReader, numWriter
  • restrict nrgt0 and numReadergt0 and
    numWritergt0
  • initial nr0 and !busy
  • module Reader()
  • integer readingF, readingT
  • initial readingFnumReader and readingT0
  • rEnter readingFgt0 and !busy and
  • nrnr1 and readingFreadingF-1 and
  • readingTreadingT1
  • rExit readingTgt0 and nrnr-1
    readingTreadingT-1 and
    readingFreadingF1
  • Reader rEnter rExit
  • endmodule
  • module Writer()
  • ...
  • endmodule
  • main Reader() Writer()

Variables introduced by the counting abstractions
76
Verification of Readers-Writers
Integers Booleans Cons. Time (secs.) Ver. Time (secs.) Memory (Mbytes)
RW-4 1 5 0.04 0.01 6.6
RW-8 1 9 0.08 0.01 7
RW-16 1 17 0.19 0.02 8
RW-32 1 33 0.53 0.03 10.8
RW-64 1 65 1.71 0.06 20.6
RW-P 7 1 0.05 0.01 9.1
77
Outline
  • Model checking with arithmetic constraints
  • Conservative approximations
  • Automata representation for arithmetic
    constraints
  • Composite representation
  • Action Language Verifier (ALV)
  • Checking synchronization in concurrent programs
    with ALV

78
Design for Verification
Action Language Verifier
Design for Verification
enables
uses
Verification of Synchronization in
Concurrent Programs
79
A Java Read-Write Lock Implementation
How do we translate this to Action Language?
  • class ReadWriteLock    private Object lockObj   
    private int totalReadLocksGiven   private boolean
     writeLockIssued   private int threadsWaitingForW
    riteLock   public ReadWriteLock()      lockObj 
     new Object()     writeLockIssued  false     
      public void getReadLock()      synchronized (lo
    ckObj)        while ((writeLockIssued)  (thread
    sWaitingForWriteLock ! 0))          try        
        lockObj.wait()          catch (InterruptedEx
    ception e)                        totalReadLock
    sGiven           public void getWriteLock() 
        synchronized (lockObj)        threadsWaiting
    ForWriteLock       while ((totalReadLocksGiven
     ! 0)  (writeLockIssued))          try       
         lockObj.wait()          catch (InterruptedE
    xception e)            //                      
     threadsWaitingForWriteLock--       writeLockIssu
    ed  true           public void done()      sy
    nchronized (lockObj)        //check for errors  
         if ((totalReadLocksGiven  0)  (!writeLock
    Issued))          System.out.println(" Error Inv
    alid call to release the lock")         return  
                if (writeLockIssued)         writeLoc
    kIssued  false       else         totalReadLocks
    Given--       lockObj.notifyAll()        

Action Language Verifier
Verification of Synchronization in Java Programs
80
Design for Verification
  • Abstraction and modularity are key both for
    successful designs and scalable verification
    techniques
  • The question is
  • How can modularity and abstraction at the design
    level be better integrated with the verification
    techniques which depend on these principles?
  • Our approach
  • Structure software in ways that facilitate
    verification
  • Document the design decisions that can be useful
    for verification
  • Improve the applicability and scalability of
    verification using this information

81
A Design for Verification Approach
  • We have been investigating a design for
    verification approach based on the following
    principles
  • Use of design patterns that facilitate automated
    verification
  • Use of stateful, behavioral interfaces which
    isolate the behavior and enable modular
    verification
  • An assume-guarantee style modular verification
    strategy that separates verification of the
    behavior from the verification of the conformance
    to the interface specifications
  • A general model checking technique for interface
    verification
  • Domain specific and specialized verification
    techniques for behavior verification
  • Avoids usage of error-prone Java synchronization
    primitives
  • synchronize, wait, notify
  • Separates controller behavior from the threads
    that use the controller
  • Supports a modular verification approach
    which exploits this modularity
  • for scalable verification

82
Reader-Writer Controller
This helper class is provided. No need to rewrite
it!
  • class Action
  • protected final Object owner
  • private boolean GuardedExecute()
  • boolean resultfalse
  • for(int i0 iltgcV.size() i) try
  • if(((GuardedCommand)gcV.get(i)).guard())
  • ((GuardedCommand)gcV.get(i)).update()
  • resulttrue break
  • catch(Exception e)
  • return result
  • public void blocking()
  • synchronized(owner)
  • while(!GuardedExecute())
  • tryowner.wait()
  • catch (Exception e)
  • owner.notifyAll()
  • public boolean nonblocking()
  • class RWController implements RWInterface
  • int nR boolean busy
  • final Action act_r_enter, act_r_exit
  • final Action act_w_enter, act_w_exit
  • RWController()
  • ...
  • gcs new Vector()
  • gcs.add(new GuardedCommand()
  • public boolean guard()
  • return (nR 0 !busy)
  • public void update()busy true
  • )
  • act_w_enter new Action(this,gcs)
  • public void w_enter()
  • act_w_enter.blocking()
  • public boolean w_exit()
  • return act_w_exit.nonblocking()
  • public void r_enter()

83
Controller Interfaces
  • A controller interface defines the acceptable
    call sequences for the threads that use the
    controller
  • Interfaces are specified using finite state
    machines
  • public class RWStateMachine implements
    RWInterface
  • StateTable stateTable
  • final static int idle0,reading1, writing2
  • public RWStateMachine() ...
    stateTable.insert("w_enter",idle,writing)
  • public void w_enter()
  • stateTable.transition("w_enter")
  • ...

reading
r_enter
r_exit
idle
w_exit
writing
w_enter
84
Verification Framework
Behavior Verification
Action Language Verifier
Controller Behavior Machine
Controller Classes
Counting Abstraction
Concurrent Program
Controller Interface Machine
Interface Verification
Java Path Finder
Thread
Thread Isolation
Thread
Thread Class
Thread Classes
85
Modular Design / Modular Verification
Thread Modular Interface Verification
Concurrent Program
Thread 1
Thread 2
Thread n
Thread 1
Thread 2
Thread n
Interface Machine
Interface Machine
Interface Machine
Interface
Controller
Modular Behavior Verification
Shared Data
Controller Behavior
86
Behavior Verification
  • Analyzing properties (specified in CTL) of the
    synchronization policy encapsulated with a
    concurrency controller and its interface
  • Verify the controller properties assuming that
    the user threads adhere to the controller
    interface
  • Behavior verification with Action Language
    Verifier
  • We wrote a translator which translates controller
    classes to Action Language
  • Using counting abstraction we can check
    concurrency controller classes for arbitrary
    number of threads

87
Interface Verification
  • A thread is correct with respect to an interface
    if all the call sequences generated by the thread
    can also be generated by the interface machine
  • Checks if all the threads invoke controller
    methods in the order specified in the interfaces
  • Checks if the threads access shared data only at
    the correct interface states
  • Interface verification with Java PathFinder
  • Verify Java implementations of threads
  • Correctness criteria are specified as assertions
  • Look for assertion violations
  • Assertions are in the StateMachine and SharedStub
  • Performance improvement with thread Isolation

88
Thread Isolation Part 1
  • Interaction among threads
  • Threads can interact with each other in only two
    ways
  • invoking controller actions
  • invoking shared data methods
  • To isolate the threads
  • Replace concurrency controllers with controller
    interface state machines
  • Replace shared data with shared stubs

89
Thread Isolation Part 2
  • Interaction among a thread and its environment
  • Modeling threads call to its environment with
    stubs
  • File I/O, updating GUI components, socket
    operations, RMI call to another program
  • Replace with pre-written or generated stubs
  • Modeling the environments influence on threads
    with drivers
  • Thread initialization, RMI events, GUI events
  • Enclose with drivers that generate all possible
    events that influence controller access

90
Automated Airspace Concept
  • Automated Airspace Concept by NASA researchers
    automates the decision making in air traffic
    control
  • The most important challenge is achieving high
    dependability
  • Automated Airspace Concept includes a failsafe
    short term conflict detection component called
    Tactical Separation Assisted Flight Environment
    (TSAFE)
  • It is responsible for detecting conflicts in
    flight plans of the aircraft within 1 minute from
    the current time
  • Dependability of this component is even more
    important than the dependability of the rest of
    the system
  • It should be a smaller, isolated component
    compared to the rest of the system so that it can
    be verified

91
TSAFE
  • TSAFE functionality
  • Display aircraft position
  • Display aircraft planned route
  • Display aircraft future projected route
    trajectory
  • Show conformance problems

92
TSAFE Architecture
ltltTCP/IPgtgt
User
Server
Radar feed
Client
EventThread
ltltRMIgtgt
21,057 lines of code with 87 classes
93
Behavior Verification Performance
Controller Time(sec) Memory (MB) P-Time (sec) P-Memory (MB)
RW 0.17 1.03
Mutex 0.01 0.23
Barrier 0.01 0.64
BB-RW 0.13 6.76
BB-Mutex 0.63 1.99
8.10 12.05
0.98 0.03
0.01 0.50
0.63 10.80
2.05 6.47
P denotes parameterized verification for
arbitrary number of threads
94
Interface Verification Performance
Thread Time (sec) Memory (MB)
TServer-Main 67.72 17.08
TServer-RMI 91.79 20.31
TServer-Event 6.57 10.95
TServer-Feed 123.12 83.49
TClient-Main 2.00 2.32
TClient-RMI 17.06 40.96
TClient-Event 663.21 33.09
95
Fault Categories
  • Concurrency controller faults
  • initialization faults (2)
  • guard faults (2)
  • update faults (6)
  • blocking/nonblocking faults (4)
  • Interface faults
  • modified-call faults (8)
  • conditional-call faults
  • conditions based on existing program variables
    (13)
  • conditions on new variables declared during fault
    seeding (5)

96
Effectiveness in Finding Faults
  • Created 40 faulty versions of TSAFE
  • Each version had at most one interface fault and
    at most one behavior fault
  • 14 behavior and 26 interface faults
  • Among 14 behavior faults ALV identified 12 of
    them
  • 2 uncaught faults were spurious
  • Among 26 interface faults JPF identified 21 of
    them
  • 2 of the uncaught faults were spurious
  • 3 of the uncaught faults were real faults that
    were not caught by JPF

97
Falsification Performance
Thread Time (sec) Memory (MB)
TServer-RMI 29.43 24.74
TServer-Event 6.88 9.56
TServer-Feed 18.51 94.72
TClient-RMI 10.12 42.64
TClient-Event 15.63 12.20
Concurrency Controller Time (sec) Memory (MB)
RW-8 0.34 3.26
RW-16 1.61 10.04
RW-P 1.51 5.03
Mutex-8 0.02 0.19
Mutex-16 0.04 0.54
Mutex-p 0.12 0.70
98
Conclusions
  • Infinite state model checking is feasible
  • Enables verification of specifications with
    unbounded variables
  • Enables verification of parameterized systems
  • Infinite state verification techniques can help
    us in identifying more efficient finite state
    model checking techniques
  • Building extensible tools is important!

99
Conclusions
  • Application of automated verification techniques
    to real-world systems leads to re-thinking the
    design
  • Design for verification can lead to more
    effective verification
  • Integrating verification tools lead to more
    effective verification
  • In our case ALV and JPF

100
Conclusions
  • We were able to use our design for verification
    approach based on design patterns and behavioral
    interfaces in different domains
  • Use of domain specific behavior verification
    techniques has been very effective
  • Interface verification was the bottleneck
  • Model checking research resulted in various
    verification techniques and tools which can be
    customized for specific classes of software
    systems
  • Automated verification techniques can scale to
    realistic software systems using design for
    verification approach

101
THE END
About PowerShow.com