Specification, Verification, and Synthesis of Concurrency Control Components

1
Specification, Verification, and Synthesis of
Concurrency Control Components

• Tuba Yavuz-Kahveci
• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• tuba,bultan_at_cs.ucsb.edu

2
Problem

• Concurrent programming is difficult and error
  prone
• Sequential programming states of the variables
• Concurrent programming states of the variables
  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

3
Our Approach

• Specification of the concurrency component
• Using Action Language
• Automated verification
• Using an infinite state model checker
• Action Language Verifier
• Automated code synthesis
• Using a symbolic representation manipulator
• Composite Symbolic Library

4
Tools for Specification, Verification, and
Synthesis of Concurrent Systems
Action Language Specification of the
Concurrency Component
Action Language Parser
Code Generator
Omega Library
CUDD Package
Verified code
5
Outline

• Monitors
• Specification of Monitors
• Action Language
• Verification
• Action Language Verifier
• Code Synthesis
• Case Study Airport Ground Traffic Control
• Experiments
• Related Work
• Conclusions

6
Concurrency Control with Monitors

• A set of variables
• Modeling shared resources
• Cannot be accessed outside of the monitor
• A set of procedures
• Only one can be active at any time
• Provided my the monitor semantics
• Synchronization among concurrent processes
• Using condition variables

7
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

8
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

9
Java Monitors

• A simplified implementation of Hoare monitors
• No separate notion of condition variables
• Can be simulated by objects
• Each object associated with a mutual exclusion
  lock
• synchronized(o)
• Synchronized methods
• wait(), notify(), notifyAll()
• Implementing monitors is complicated
• To implement a monitor as a Java class
• Shared resources must be implemented using
  private fields
• All methods can change state of the fields only
  in synchronized blocks

10
Outline

• Monitors
• Specification of Monitors
• Action Language
• Verification
• Action Language Verifier
• Code Synthesis
• Case Study Airport Ground Traffic Control
• Experiments
• Related Work
• Conclusions

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
• Parameterized constants
• 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
• CTL properties
• Invariant(p) p always holds
• Eventually(p) p eventually holds

12
Readers Writers
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
P Temporal property of main module
13
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

14
Readers-Writers Monitor Specification After
Counting Abstraction
Parameterized constants representing the number
of readers and number of writers

• 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 and
• readingTreadingT-1 and
  
  readingFreadingF1
• Reader rEnter rExit
• endmodule

Variables for counting the number of processes in
specific local states
Initialize initial local state counter by the
relevant parameterized constant. Initialize other
local states to 0
When local state changes, decrement current local
state counter and increment next local state
counter
15
Outline

• Monitors
• Specification of Monitors
• Action Language
• Verification
• Action Language Verifier
• Code Synthesis
• Case Study Airport Ground Traffic Control
• Experiments
• Related Work
• Conclusions

16
Action Language Verifier

• An infinite state symbolic model checker
• Composite representation
• uses a disjunctive representation to combine
  different symbolic representations
• Computes fixpoints by manipulating formulas in
  composite representation
• Heuristics to ensure convergence
• Widening collapsing
• Loop closure
• Approximate reachable states

17
Composite Symbolic Library Class Diagram
Symbolic

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

CUDD Library
OMEGA Library
18
Outline

• Monitors
• Specification of Monitors
• Action Language
• Verification
• Action Language Verifier
• Code Synthesis
• Case Study Airport Ground Traffic Control
• Experiments
• Related Work
• Conclusions

19
Synthesizing the Implementation of the Monitor

• Automated generation of 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!
• The condition variables can be synthesized
  automatically
• There is no unnecessary thread notification

20
Naïve Translation Redundant Signaling
public class SetAB private boolean a.b
public setAB() a true b
true public synchronized SetA()
while (!b) try wait() catch().. a
true b false notifyAll()
public synchronized SetB() while
(!a) trywait() catch() a
false b true notifyAll()

Module main() boolean a,b initial a
and b module SetA() SetA b and
atrue and bfalse endmodule
module SetB() SetB a and afalse
and btrue endmodule main setA()
setB() endmodule

Action Language Specification
Implementation in Java
21
Specific Notification Pattern
class SetAB private boolean a.b private
Object condA, condB private
synchronized boolean Guard_SetA() if (b)
a true b false return true else
return false public void SetA()
synchronized(condB) while
(!Guard_SetA()) try condB.wait()
catch() condA.notifyAll()
public void SetB()
synchronized(condA) while
(!Guard_SetB()) try condA.wait()
catch() .. condB.notifyAll()

Module main() boolean a,b initial a
and b module SetA() SetA b and
atrue and bfalse endmodule
module SetB() SetB a and afalse
and btrue endmodule main setA()
setB() endmodule
Action Language Specification
Implementation in Java
22
Algorithm for Extracting Synchronization
Information

• for each action A do
• // Does A check any condition?
• if ds(A) ? true then
• mark A as guarded
• create condition variable condA
• else
• mark A as unguarded
• for each action B s.t. A ? B do
• // Can A change the condition B waits on
  from false to true?
• if POST(? ds(B),EXP(A)) ? ds(B) ? ? then
• add condB to notification list of A

23
Readers-Writer Example with 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
24
Outline

• Monitors
• Specification of Monitors
• Action Language
• Verification
• Action Language Verifier
• Code Synthesis
• Case Study Airport Ground Traffic Control
• Experiments
• Related Work
• Conclusions

25
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
• Simulate behavior of each airplane with a thread
• Use a monitor which keeps track of number of
  airplanes on each runway and each taxiway

26
A simplified model of Seattle Tacoma
International Airport from Zhong 97
27
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 14 condition variables
• Has 34 procedures

28
Experiments
A Arriving Airplane D Departing Airplane P
Arbitrary number of processes
29
Related Work Demartini et al., 99, Corbett
et al., 00, Havelund et al., 00

• Extracting compact models from the implementation
• Employing techniques such as slicing and
  abstraction
• Automated verification of the model
• Finite state model checker
• Explicit state model checking techniques

30
Related Work Mizuno-99

• Given a concurrency problem and a global
  invariant
• Provides a course-grain solution
• ltawait B Sgt or ltSgt
• Translates the course-grain solution to a Java
  program
• Using Specific Notification Pattern
• Creates a separate condition variable cB for each
  guard B
• When S may change B to true cB is signaled
• Preserving the global invariant
• Not automated

31
Related WorkDeng et al., 02

• Extends and automates Mizunos approach
• Synthesizes the code from a global invariant
• A logic formula
• Uses a decision procedure
• A pattern specification
• Bound, Exclusion, Resource, Barrier, Relay, and
  Group
• Automatically verifies
• synthesized synchronization code functional
  application code
• Uses a finite state model checker

32
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
• SAS02 Verification of Concurrent Linked Lists

33
Readers Writers Monitor 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

34
Action Language Verifier

• An infinite state symbolic model checker
• Uses composite symbolic representation to encode
  a system defined by (S,I,R)
• S set of states, I set if initial states, R
  transition relation
• Maps each variable type to a symbolic
  representation type
• Maps boolean and enumerated types to BDD
  representation
• Maps integer type to arithmetic constraint
  representation
• Uses a disjunctive representation to combine
  symbolic representations
• Each disjunct is a conjunction of formulas
  represented by different symbolic representations

35
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
36
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

37
Synchronization Among Processes
Executing Process
Ready Queue
Processk
Processk
Processi
Processk
Processm
condA
Waiting Queue
Processm
Processi