Tools%20for%20Specification,%20Verification,%20and%20Synthesis%20of%20Concurrency%20Control%20Components

1
Tools for Specification, Verification, and
Synthesis of Concurrency Control Components

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan/
• http//www.cs.ucsb.edu/bultan/composite/

2
Students

• Tuba Yavuz-Kahveci
• Xiang Fu
• Constantinos Bartzis
• Murat Tuncer
• Aysu Betin

3
Problem

• Concurrent programming is difficult and error
  prone
• In sequential programming you only worry about
  the states of the variables, in concurrent
  programming you also have to worry about the
  states of the processes
• When there is concurrency, testing is not enough
• State space increases exponentially with the
  number of processes
• We would like to guarantee certain properties of
  a concurrent system

4
Airport Ground Traffic Control
A simplified model of Seattle Tacoma
International Airport from Zhong 97
5
Airport Ground Traffic Control Simulator

• Simulate behavior of each airplane with a thread
• Use a monitor which keeps track of number of
  airplanes on each runway and each taxiway
• Use guarded commands (which will become the
  procedures of the monitor) to enforce the control
  logic

6
Tools for Specification, Verification, and
Synthesis of Reactive Systems
Action Language specification
Action Language Parser
Code Generator
Omega Library
CUDD Package
Verified code
7
Applications

• Safety-critical system specifications
• SCR (tabular), Statecharts (hierarchical state
  machines) specifications Bultan, Gerber, League
  ISSTA98, TOSEM00
• Concurrent programs
• Synthesizing verified monitor classes from
  specifications Yavuz-Kahveci, Bultan, 02
• Protocol verification
• Verification of parameterized cache coherence
  protocols using counting abstraction Delzanno,
  Bultan CP01
• Verification of workflow specifications
• Verification of acyclic decision flows Fu,
  Bultan, Hull, Su TACAS01

8
Outline

• Specification Language Action Language
• Verification Engine
• Synthesizing Verified Monitors
• Conclusions

9
Some Terminology

• Model Checker A program that checks if a
  (reactive) system satisfies a (temporal) property
• Reactive System Systems which continuously
  interact with their environment without
  terminating
• Protocols
• Requirements specifications for safety critical
  systems
• Concurrent programs
• Temporal Property A property expressed using
  temporal operators such as invariant or
  eventually

10
Expressing Properties

• Properties of reactive systems are expressed in
  temporal logics using temporal operators
• Invariant(p) is true in a state if property p
  is true in every state on all execution paths
  starting at that state
• Eventually(p) is true in a state if property p
  is true at some state on every execution path
  starting from that state

11
Action Language

• A state based language
• Actions correspond to state changes
• States correspond to valuations of variables
• Integer (possibly unbounded), boolean and
  enumerated variables
• Recently, we added heap variables (i.e.,
  pointers)
• Parameterized constants (verified for every
  possible value of the constant)
• Transition relation is defined using actions
• Atomic actions Predicates on current and next
  state variables
• Action composition
• synchronous () or asynchronous ()
• Modular
• Modules can have submodules
• Modules are defined as synchronous and
  asynchronous compositions of its actions and
  submodules

12
Simple Example
module main() integer a,b,c,r restrict agt0
and bgt0 and cgt0 initial r0 module
max(x,y,result) integer x,y,result
boolean pc initial pc true a1 pc and
(x gt y) and result x and !pc a2 pc and
(y gt x) and result y and !pc max a1
a2 spec invariant(!pc gt (resultgtx and
resultgty)) endmodule main max(a,r,r)
max(b,r,r) max(c,r,r) spec eventually(rgta
and rgtb and rgtc) endmodule
13
Simple Example

• Action Language Verifier automatically verifies
  given temporal properties
• If there is an error
• a1 pc and (x gt y) and result x and !pc
• a2 pc and (y gt x) and result y and !pc
• Action Language Verifier automatically
  generates a counter-example An execution
  sequence where where x is equal to y

14
Model Checking View

• Every reactive system
• safety-critical software specification,
• cache coherence protocol,
• mutual exclusion algorithm, etc.
• is represented as a transition system
• S The set of states
• I ? S The set of initial states
• R ? S ? S The transition relation

15
Readers Writers Solution in Action Language

• 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()
• boolean writing
• initial !writing
• wEnter !writing and nr0 and !busy and
• busy and writing
• wExit writing and !writing and !busy

16
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
17
Actions in Action Language

• Atomic actions Predicates on current and next
  state variables
• Current state variables reading, nr, busy
• Next state variables reading, nr, busy
• Logical operators not (!) and () or ()
• Equality (for all variable types)
• Linear arithmetic lt, gt, gt, lt, , (by a
  constant)
• An atomic action
• !reading and !busy and nrnr1 and reading

18
Asynchronous Composition

• Asynchronous composition is equivalent to
  disjunction if composed actions have the same
  next state variables
• a1 i gt 0 and i i 1
• a2 i lt 0 and i i 1
• a3 a1 a2
• is equivalent to
• a3 (i gt 0 and i i 1)
• or (i lt 0 and i i 1)

19
Asynchronous Composition

• Asynchronous composition preserves values of
  variables which are not explicitly updated
• a1 i gt j and i j
• a2 i lt j and j i
• a3 a1 a2
• is equivalent to
• a3 (i gt j and i j) and j j
• or (i lt j and j i) and i i

20
Synchronous Composition

• Synchronous composition is equivalent to
  conjunction if two actions do not disable each
  other
• a1 i i 1
• a2 j j 1
• a3 a1 a2
• is equivalent to
• a3 i i 1 and j j 1

21
Synchronous Composition

• A disabled action does not block synchronous
  composition
• a1 i lt max and i i 1
• a2 j lt max and j j 1
• a3 a1 a2
• is equivalent to
• a3 (i lt max and i i 1 or i gt max i i)
• and (j lt max j j 1 or j gt max j j)

22
Model Checking

• Given a program and a temporal property p
• Either show that all the initial states satisfy
  the temporal property p
• set of initial states ? truth set of p
• Or find an initial state which does not satisfy
  the property p
• a state ? set of initial states ? truth set of ?p
• and generate a counter-example starting from that
  state

23
Temporal Properties ? Fixpoints

• States that satisfy Invariant(p) are all the
  states which are not in Reach(?p) The states
  that can reach ?p
• Reach(?p) can be computed as the fixpoint of the
  following functional
• F(states) ?p ? reach-in-one-step(states)
• Actually, Reach(?p) is the least-fixpoint of F

We call this backward image operation
24
Temporal Properties ? Fixpoints
backwardImage of ?p
Backward fixpoint
Initial states

?p
initial states that violate Invariant(p)
states that can reach ?p i.e., states that
violate Invariant(p)
Invariant(p)
Forward fixpoint
Initial states

?p
reachable states that violate p
reachable states of the system
forward image of initial states
25
Symbolic Model Checking

• 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

26
BDDs

• Efficient representation for boolean functions
• Disjunction, conjunction complexity at most
  quadratic
• Negation complexity constant
• Equivalence checking complexity constant or
  linear
• Image computation complexity can be exponential

27
Constraint-Based Verification

• Can we use linear arithmetic constraints as a
  symbolic representation?
• Required functionality
• Disjunction, conjunction, negation, equivalence
  checking, existential variable elimination
• Advantages
• Arithmetic constraints can represent infinite
  sets
• Heuristics based on arithmetic constraints can be
  used to accelerate fixpoint computations
• Widening, loop-closures

28
Linear Arithmetic Constraints

• Disjunction complexity linear
• Conjunction complexity quadratic
• Negation complexity can be exponential
• Because of the disjunctive representation
• Equivalence checking complexity can be
  exponential
• Uses existential variable elimination
• Image computation complexity can be exponential
• Uses existential variable elimination

29
A Linear Arithmetic Constraint Manipulator

• Omega Library Pugh et al.
• Manipulates Presburger arithmetic formulas First
  order theory of integers without multiplication
• Equality and inequality constraints are not
  enough Divisibility constraints are also needed
• Existential variable elimination in Omega
  Library Extension of Fourier-Motzkin variable
  elimination to integers
• Eliminating one variable from a conjunction of
  constraints may double the number of constraints
• Integer variables complicate the problem even
  further
• Can be handled using divisibility constraints

30
Arithmetic Constraints vs. BDDs

• Constraint based verification can be more
  efficient than BDDs for integers with large
  domains
• BDD-based verification is more robust
• Constraint based approach does not scale well
  when there are boolean or enumerated variables in
  the specification
• Constraint based verification can be used to
  automatically verify infinite state systems
• cannot be done using BDDs
• Price of infinity
• CTL model checking becomes undecidable

31
Conservative Approximations

• Compute a lower ( p? ) or an upper ( p )
  approximation to the truth set of the property (
  p )
• Model checker can give three answers

I
p
p?
p
I
p?
The property is satisfied
I dont know
sates which violate the property
I
p
? p?
p
The property is false and here is a
counter-example
32
Computing Upper and Lower Bounds

• Approximate fixpoint computations
• Widening To compute upper bound for
  least-fixpoints
• We use a generalization of the polyhedra widening
  operator by Cousot and Halbwachs
• Collapsing (dual of widening) To compute lower
  bound for greatest-fixpoints
• Truncated fixpoints To compute lower bounds for
  least-fixpoints and upper bounds for greatest
  fixpoints
• Loop-closures
• Compute transitive closure of self-loops
• Can easily handle simple loops which increment or
  decrement a counter

33
Composite Model Checking

• Each variable type is mapped to a symbolic
  representation type
• Map boolean and enumerated types to BDD
  representation
• Map integer type to arithmetic constraint
  representation
• Use a disjunctive representation to combine
  symbolic representations
• Each disjunct is a conjunction of formulas
  represented by different symbolic representations

34
Composite Formulas

• Composite formula (CF)
• CF CF ? CF CF ? CF ?CF BF IF
• Boolean Formula (BF)
• BF BF ? BF BF ? BF ?BF Termbool
• Termbool idbool true false
• Integer Formula (IF)
• IF IF ? IF IF ? IF ?IF Termint Rop
  Termint
• Termint Termint Aop Termint ?Termint
  idint constantint
• where
• Rop denotes relational operators (, ?, gt , lt,
  ?, ?),
• Aop denotes arithmetic operators (,-, and
  with a constant)

35
Composite Representation

• We represent composite formulas as disjunctions
• Each disjunct represents a conjunction of
  formulas in basic symbolic types

36
Conjunctive Decomposition

• Each composite atom is a conjunction
• Each conjunct corresponds to a different symbolic
  representation
• x integer y boolean
• xgt0 and xx1 and y?y
• Conjunct xgt0 and x?x1 will be represented by
  arithmetic constraints
• Conjunct y?y will be represented by a BDD
• Advantage Image computations can be distributed
  over the conjunction (i.e., over different
  symbolic representations).

37
Composite Symbolic Library

• Our library implements this approach using an
  object-oriented design
• A common interface is used for each symbolic
  representation
• Easy to extend with new symbolic representations
• Enables polymorphic verification
• 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

38
Composite Symbolic Library Class Diagram
Symbolic

• intersect()
• union()
• complement()
• isSatisfiable()
• isSubset()
• bacwardImage()
• forwardImage()

CUDD Library
OMEGA Library
39
Composite Symbolic Representation
x integer, yboolean (xgt0 and x?x1 and
ytrue) or (xlt0 and x?x and y?y)
CompSym
representation ListltcompAtomgt
ListNodeltcompAtomgt
ListNodeltcompAtomgt
data compAtom
data compAtom
b
0
ytrue
0
yy
1
xgt0 and xx1
1
xlt0 and xx
next ListNodeltcompAtomgt
next ListNodeltcompAtomgt
40
Satisfiability Checking

• boolean isSatisfiable(CompSym A)
• for each compAtom b in A do
• if b is satisfiable then
• return true
• return false
• boolean isSatisfiable(compAtom a)
• for each symbolic representation t do
• if at is not satisfiable then
• return false
• return true

is
Satisfiable?
true
false
false
true
is
is
is
is
and
?
Satisfiable?
Satisfiable?
Satisfiable?
41
Backward Image Composite Representation
B
A

• CompSym backwardImage(Compsym A, CompSym B)
• CompSym C
• for each compAtom d in A do
• for each compAtom e in B do
• insert backwardImage(d,e) into C
• return C

C
42
Backward Image Composite Atom

• compAtom backwardImage(compAtom a, compAtom b)
• for each symbolic representation type t do
• replace at by backwardImage(at , bt )
• return a

b
a
43
Heuristics for Efficient Manipulation of
Composite Representation

• Masking
• Mask operations on integer arithmetic constraints
  with operations on BDDs
• Incremental subset check
• Exploit the disjunctive structure by computing
  subset checks incrementally
• Merge image computation with the subset check in
  least-fixpoint computations
• Simplification
• Reduce the number of disjuncts in the composite
  representation by iteratively merging matching
  disjuncts
• Cache expensive operations on arithmetic
  constraints

44
Polymorphic Verifier

• Symbolic TranSyscheck(Node f)
• Symbolic s check(f.left)
• case EX
• s.backwardImage(transRelation)
• case EF
• do
• snew s
• sold s
• snew.backwardImage(transRelation)
• s.union(snew)
• while not sold.isEqual(s)

? Action Language Verifier is polymorphic ? When
there are no integer variable in the
specification it becomes a BDD based model
checker
45
Synthesizing Verified Monitors Yavuz-Kahveci,
Bultan 02

• Concurrent programming is difficult
• Exponential increase in the number of states by
  the number of concurrent components
• Monitors provide scoping rules for concurrency
• Variables of a monitor can only be accessed by
  monitors procedures
• No two processes can be active in a monitor at
  the same time
• Java made programming using monitors a common
  problem

46
Monitor Basics

• A monitor has
• A set of shared variables
• A set of procedures
• which provide access to the shared variables
• A lock
• To execute a monitor procedure a process has to
  grab the monitor lock
• Only one process can be active (i.e. executing a
  procedure) in the monitor at any given time

47
Monitor Basics

• What happens if a process needs to wait until a
  condition becomes true?
• Create a condition variable that corresponds to
  that condition
• Each condition variable has a wait queue
• A process waits for a condition in the wait queue
  of the corresponding condition variable
• When a process updates the shared variables that
  may cause a condition to become true
• ? it signals the processes in the wait
  queue of the corresponding condition variable

48
Monitors

• Challenges in monitor programming
• Condition variables
• Wait and signal operations
• Why not use a single wait queue?
• Inefficient, every waiting process has to wake up
  when any of the shared variables are updated
• Even with a few condition variables coordinating
  wait and signal operations can be difficult
• Avoid deadlock
• Avoid inefficiency due to unnecessary signaling

49
Monitor Specifications in Action Language

• Monitors with boolean, enumerated and integer
  variables
• Condition variables are not necessary in Action
  Language
• Semantics of Action Language ensures that an
  action is executed when it is enabled
• We can automatically verify Action Language
  specifications
• We can automatically synthesize efficient monitor
  implementations from Action Language
  specifications

50
Readers-Writers Monitor Specification

• 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()
• boolean writing
• initial !writing
• wEnter !writing and nr0 and !busy and
• busy and writing
• wExit writing and !writing and !busy

51
What About Arbitrary Number of Processes?

• Use counting abstraction
• Create an integer variable for each local state
  of a process type
• Each variable will count the number of processes
  in a particular state
• Local states of the process types have to be
  finite
• Specify only the process behavior that relates to
  the correctness of the monitor
• Shared variables of the monitor can be unbounded
• Counting abstraction can be automated

52
Readers-Writers Monitor Specification After
Counting Abstraction

• 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()

53
Verification of Readers-Writers Monitor
Specification
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
SUN ULTRA 10 (768 Mbyte main memory)
54
What about the Implementation of the Monitor?

• We can automatically generate code from the
  monitor specification
• Generate a Java class
• Make shared variables private variables
• Use synchronization to restrict access
• Is the generated code efficient
• Yes!
• We can synthesize the condition variables
  automatically
• There is no unnecessary thread notification

55
Synthesized Monitor Class Uses Specific
Notification Pattern

• public class ReadersWriters
• private int nr
• private boolean busy
• private Object rEnterCond, wEnterCond
• private synchronized boolean Guard_rEnter()
• if (!busy)
• nr
• return true
• else return false
• public void rEnter()
• synchronized(rEnterCond)
• while(!Guard_rEnter())
• rEnterCond.wait()
• public void rExit()
• synchronized(this) nr--
• synchronized(wEnterCond) wEnterCond.notify()
  

All condition variables and wait and signal
operations are generated automatically
56
Airport Ground Traffic Control

• Zhong 97 Modeling of airport operations using
  an object oriented approach
• A concurrent program simulating the airport
  ground traffic control
• multiple planes
• multiple runways and taxiways
• Can be used by controllers as advisory input

57
A simplified model of Seattle Tacoma
International Airport from Zhong 97
58
Control Logic

• An airplane can land using 16R only if no
  airplane is using 16R at the moment
• An airplane can takeoff using 16L only if no
  airplane is using 16L at the moment
• An airplane taxiing on one of the exits C3-C8 can
  cross runway 16L only if no airplane is taking
  off at the moment
• An airplane can start using 16L for taking off
  only if none of the crossing exits C3-C8 is
  occupied at the moment (arriving airplanes have
  higher priority)
• Only one airplane can use a taxiway at a time

59
Airport Ground Traffic Control Simulator

• Simulate behavior of each airplane with a thread
• Use a monitor which keeps track of number of
  airplanes on each runway and each taxiway
• Use guarded commands (which will become the
  procedures of the monitor) to enforce the control
  logic

60
Airport Ground Traffic Control Monitor

• Action Language specification
• Has 13 integer variables
• Has 4 Boolean variables per arriving airplane
  process to keep the local state of each airplane
• Has 2 Boolean variables per departing airplane
  process to keep the local state of each airplane
• Automatically generated monitor class
• Has 13 integer variables
• Has 20 condition variables
• Has 34 procedures

61
Experiments
Processes Construction Verify-P1 Verify-P2 Verify-P3
2 0.81 0.42 0.28 0.69
4 1.50 0.78 0.50 1.13
8 3.03 1.53 0.99 2.22
16 6.86 3.02 2.03 5.07
2A,PD 1.02 0.64 0.43 0.83
4A,PD 1.94 1.19 0.81 1.39
8A,PD 3.95 2.28 1.54 2.59
16A,PD 8.74 4.6 3.15 5.35
PA,2D 1.67 1.31 0.88 3.94
PA,4D 3.15 2.42 1.71 5.09
PA,8D 6.40 4.64 3.32 7.35
PA,16D 13.66 9.21 7.02 12.01
PA,PD 2.65 0.99 0.57 0.43
62
Conclusions and Future Work

• We can automatically verify and synthesize
  nontrivial monitors in Java
• Our tools can deal with boolean, enumerated and
  (unbounded) integer variables
• What about recursive data types?
• shape analysis
• What about arrays?
• uninterpreted functions