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 CheckingMcMillan 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 CheckingBultan 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. BDDsBultan 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
EncodingBartzis, 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
EncodingCAV04

• 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 CheckingBultan, 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
GraphsYavuz-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