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}@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. Action Language Verifier Composite Symbolic Library 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. S :Cartesian product of variable domains defines the set of states Readers Writers I : Predicates defining the initial states module main() integer nr; boolean busy; restrict: nr>=0; initial:nr=0 and !busy; module Reader() booleanreading; initial:!reading; rEnter:!reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader:rEnter | rExit; endmodule module Writer() ... endmodule main:Reader() | Reader() | Writer() | Writer(); spec:invariant([busy => nr=0]) endmodule 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 integernumReader, numWriter; restrict: nr>=0 and numReader>=0 and numWriter>=0; initial: nr=0 and !busy; module Reader() integerreadingF, readingT; initial:readingF=numReader and readingT=0; rEnter: readingF>0 and !busy and nr’=nr+1 and readingF’=readingF-1 and readingT’=readingT+1; rExit: readingT>0 and nr’=nr-1 and readingT’=readingT-1 and readingF’=readingF+1; Reader: rEnter | rExit; endmodule ... main: Reader() | Writer(); spec: invariant([busy => nr=0]) 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. BoolSym CompSym IntSym –representation: BDD –representation: Polyhedra –representation: list of comAtom +intersect() +union() • • • +intersect() +union() • • • +intersect() + union() • • • compAtom –atom: *Symbolic 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) try{wait();} catch(…){…} a = false; b = true; notifyAll(); } } Module main() boolean a,b; initial: a and b; module SetA() SetA: b and a’=true and b’=false; endmodule module SetB() SetB: a and a’=false and b’=true; 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 a’=true and b’=false; endmodule module SetB() SetB: a and a’=false and b’=true; endmodule main: setA() | setB() … endmodule Action Language Specification Implementation in Java

22. Algorithm for Extracting Synchronization Information for each action Ado // Does A check any condition? ifds(A) truethen mark A as guarded create condition variable condA else mark A as unguarded for each action B s.t. A  Bdo // Can A change the condition B waits on from false to true? ifPOST( 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. A: Arriving Airplane D: Departing Airplane P: Arbitrary number of processes Experiments

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 • <await B; S> or <S> • 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 Work[Deng et al., 02] • Extends and automates Mizuno’s 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 • [SAS’02] Verification of Concurrent Linked Lists

33. Readers Writers Monitor in Action Language modulemain() integer nr; boolean busy; restrict: nr>=0; initial: nr=0 and !busy; module Reader() boolean reading; initial: !reading; rEnter: !reading and !busy and nr’=nr+1 and reading’; rExit: reading and !reading’ and nr’=nr-1; Reader: rEnter | rExit; endmodule module Writer() boolean writing; initial: !writing; wEnter: !writing and nr=0 and !busy and busy’ and writing’; wExit: writing and !writing’ and !busy’; Writer: wEnter | wExit; endmodule main: Reader() | Reader() | Writer() | Writer(); spec:invariant([busy => nr=0]) endmodule

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 forward image of initial states reachable states of the system

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. wait signal Synchronization Among Processes Executing Process Ready Queue Processk Processk Processi Processk Processm condA Waiting Queue Processm Processi