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. Tools for Specification, Verification, and Synthesis of Concurrent Systems Action Language Specification of the Concurrency Component Action Language Parser Verifier Composite Symbolic Library Code Generator OmegaLibraryCUDDPackage 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 module main() 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()... endmodule main: Reader() | Reader() | Writer() | Writer(); spec: invariant([busy => nr=0]) endmodule S : Cartesian product of variable domains defines variable domains defines the set of states the set of states I : Predicates defining the initial states the initial states R : Atomic actions of the Reader 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 module main() integer nr; boolean busy; parameterized integer numReader, numWriter; restrict: nr>=0 and numReader>=0 and numWriter>=0; initial: nr=0 and !busy; module Reader() integer readingF, 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 Parameterized constants representing the number of readers and number of writers Variables for counting the number of processes in specific local states When local state changes, decrement current local state counter and increment next local state counter Initialize initial local state counter by the relevant parameterized constant. Initialize other local states to 0

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 CUDD LibraryOMEGA Library Symbolic +intersect() +union() +complement() +isSatisfiable() +isSubset() +bacwardImage() +forwardImage() CompSym –representation: list of comAtom +intersect() + union() BoolSym –representation: BDD +intersect() +union() IntSym –representation: Polyhedra +intersect() +union() compAtom –atom: *Symbolic

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 Module main() boolean a,b; boolean a,b; initial: a and b; initial: a and b; module SetA() module SetA() SetA: b and a’=true SetA: b and a’=true and b’=false; and b’=false; endmodule endmodule module SetB() module SetB() SetB: a and a’=false SetB: a and a’=false and b’=true; and b’=true; endmodule endmodule main: setA() | setB() main: setA() | setB() …endmodule public class SetAB { private boolean a.b; private boolean a.b; public setAB() { public setAB() { a = true; a = true; b = true; b = true; } public synchronized SetA() { public synchronized SetA() { while (!b) while (!b) try{ wait();} catch(…){..} a = true; a = true; b = false; b = false; notifyAll(); notifyAll(); } public synchronized SetB() { public synchronized SetB() { while (!a) while (!a) try{wait();} catch(…){…} a = false; a = false; b = true; b = true; notifyAll(); notifyAll(); }} Action Language Specification Implementation in Java

21. Specific Notification Pattern Module main() boolean a,b; boolean a,b; initial: a and b; initial: a and b; module SetA() module SetA() SetA: b and a’=true SetA: b and a’=true and b’=false; and b’=false; endmodule endmodule module SetB() module SetB() SetB: a and a’=false SetB: a and a’=false and b’=true; and b’=true; endmodule endmodule main: setA() | setB() main: setA() | setB() …endmodule Action Language Specification class SetAB { private boolean a.b; private boolean a.b; private Object condA, condB; private Object condA, condB; … private synchronized boolean Guard_SetA() { private synchronized boolean Guard_SetA() { if (b) { a = true; b = false; return true;} if (b) { a = true; b = false; return true;} else return false; else return false; } public void SetA() { public void SetA() { synchronized(condB) { synchronized(condB) { while (!Guard_SetA()) while (!Guard_SetA()) try{ condB.wait(); } catch(…) {…} try{ condB.wait(); } catch(…) {…} } condA.notifyAll(); condA.notifyAll(); } public void SetB() { public void SetB() { synchronized(condA) { synchronized(condA) { while (!Guard_SetB()) while (!Guard_SetB()) try{ condA.wait(); } catch(…) {..} try{ condA.wait(); } catch(…) {..} } condB.notifyAll(); condB.notifyAll(); }} Implementation in Java

22. Algorithm for Extracting Synchronization Information for each action A do // Does A check any condition? if d s (A)  true then mark A as guarded create condition variable cond A 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(  d s (B),EXP(A))  d s (B)   then add cond B 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 ProcessesConstruction (sec) Verify-P1 (sec) Verify-P2 (sec) Verify-P3 (sec) 20.810.420.280.69 41.500.780.501.13 83.031.530.992.22 166.863.022.035.07 2A,PD1.020.640.430.83 4A,PD1.941.190.811.39 8A,PD3.952.281.542.59 16A,PD8.744.63.155.35 PA,2D1.671.310.883.94 PA,4D3.152.421.715.09 PA,8D6.404.643.327.35 PA,16D13.669.217.0212.01 PA,PD2.650.990.570.43 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 or Translates the course-grain solution to a Java program –Using Specific Notification Pattern Creates a separate condition variable c B for each guard B When S may change B to true c B 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 module main() 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 Invariant(p) pppp Initialstates initial states that violate Invariant(p) Backwardfixpoint Forwardfixpoint Initialstates states that can reach  p i.e., states that violate Invariant(p) reachable states of the system pppp backwardImage of  p of  p reachable states that violate p 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 condA signal Ready Queue Executing Process Process k wait Waiting Queue Process i Process m Process k Process i Process k