1. Automatic Derivation, Integration, and Verification of Synchronization Aspects in Object-Oriented Design Methods Principal Investigators Matt Dwyer John Hatcliff Masaaki Mizuno Mitch Nielsen Gurdip Singh Department of Computing and Information Sciences Kansas State University http://www.cis.ksu.edu/santos

2. Collaborative Research at K-State SANTOS Group –Programming Languages/Semantics –Software Specifications –Software Model Checking (Bandera) Systems Group –Distributed/Operating Systems, Networking, Synchronization –Object Orientation –Embedded Systems (CAN systems)

3. Problem Statement :Card Reader :Display:Key Pad :Client Manager :Cash Counter :Trans Manager Card inserted (ID) Insert Card Show request Specify PIN code PIN Code (PIN) Ask for PIN code Request PIN validation Ask for amount to withdraw Show request …an effective way to develop a set of sequential codes which are executed by threads. …DOES NOT provide a standard methodology to develop synchronization among such threads. Rational Unified Process (RUP) in the Unified Modeling Language (UML) is the de facto standard for OO development process.

4. Our Theme …Focus on building core functional code (minus synchronization) …Give formal high-level spec of synchronization behavior …Correct synchronization code is synthesized and linked in automatically

5. Goals of the Project II. Automatic derivation and weaving of synchronization code … multiple language and synchronization targets (Java, C++, monitors, semaphores, etc.) … weaving & optimization via abstract interpretation and program specialization techniques III. Automatic verification of critical safety and liveness properties of woven embedded code … domain-specific model-checking engines … built on previous DARPA work – Bandera environment I. Provide high-level, modular specification of global synchronization aspects … integrated with UML/RUP … formal specification via global invariants … language of composable invariant patterns … powerful, yet easy to use IV. Evaluation using military networking target vehicle electronics (CDA101)

6. Global Invariant Approach ReadersWriter Buffer Assume each region has associated implicit in and out counters that are incremented as regions are entered and exited Step 1 Identify intended critical regions State a global invariant constraining occupancy of the regions && (W_in – W_out <= 1) R_in++ R_out++ Implicit W_in++ W_out++ Implicit (R_in – R_out == 0 || W_in – W_out == 0) Invariant:

7. Global Invariant Approach ReadersWriter Buffer C> …wait until B then execute C atomically …execute C atomically Step 2 Use invariant to guide formulation of guards for region enter/exit && (W_in – W_out <= 1)(R_in – R_out == 0 || W_in – W_out == 0) Invariant: <await W_in–W_out == 0 -> R_in++> <await R_in–R_out == 0 && W_in-W_out == 0 -> W_in++> Called the “coarse-grain” solution

8. Global Invariant Approach ReadersWriter Buffer …monitors, rendezvous, semaphores, etc… Step 3 Translate await and atomic statements to chosen synchronization mechanism Monitor Proc R_Enter() … …; Proc R_Exit() … …; Proc W_Enter() … …; Proc W_Exit() … …; Monitor Call R_Enter; Call R_Exit; Call W_Enter; Call W_Exit; Called the “fine-grain” solution

9. Advantages of Our Global Invariant Approach “Aspect-oriented” –Synchronization aspect is cleanly factored out Formal approach –Enables rigorous reasoning about synchronization aspects Synchronization coding lies at a high level –Namely, the specification of invariants Global invariants are independent of platform, language and synchronization primitive

10. Our Approach --- Invariant Patterns Users never write formulas but instead build invariants using a collection of global invariant patterns… Bound(R,n) … at most n threads can be in region R Exclusion(R1,R2) … occupancy of region R1 and R2 should be mutually exclusive Resource(R1, R2, n) … region R1 is a producer, region R2 is a consumer of some resource with n initial resource values. Barrier(R1,R2) … the k th thread to enter R1 and the k th thread to enter R2 meet and leave their respective regions together Barrier with information interchange… Complex Barrier…

11. Our Approach --- Invariant Patterns Users never write formulas but instead build invariants using a collection of global invariant patterns… Bound(R,n) …at most n threads can be in region R Exclusion(R1,R2) … occupancy of region R1 and R2 should be mutually exclusive Example: Readers/Writers Exclusion(R,W) + Bound(W,1)

12. Our Approach --- Automatic Synthesis Both coarse-grain and fine-grain solutions are synthesized automatically.java + Invariant Fine-grain Java Representation Generator Intermediate Representation Generator PVS.java + guarded commands.java + Core code Synchronization aspect

13. Tool Architecture UML Tools Synchronization Aspect Specification Tool Intermediate Representation Generator Solver/ Prover Course-grain solution Synchronization Aspect Back-end Bandera Analysis & Transformation Fine-grain solution Specialization Engine Bandera Safety Properties Liveness Properties Code Weaver Optimized Woven Code Invariant & Region tags Functional Core Code Templates (Java, C++, …) Template Instantiation Traditional Development Environment Functional Core Code (Java, C++, …) Finite State Models

14. Example: Vessel Control SensorsActuators Engine ControllerRudder Controller Rudder Sensor Rudder Pump Throttle Controller Throttle Fiber/TP HubGPS Other Sensors and Actuators CAN Bus …from Navy SEABORNE target vehicle documentation

15. Gyroscope/Rudder Sub-system Gyroscope Controller Buffer Rudder Controller Gyroscope produces position values which are placed in a single entry buffer Rudder controller reads position values from buffer and uses them to actuate the rudder

16. Use Cases and Critical Regions Gyroscope ControllerRudder Controller Read a value from the gyroscope Wait until the buffer becomes empty Write a new value in the buffer Wait until gyroscope value is in buffer Read value from buffer Actuate rudder based on value Critical Region: R G Critical Region: R R Identify segments (a) that must wait for some even to occur (b) segments that cause events waited for in (a)

17. Gyroscope/Rudder Synchronization Gyroscope Controller Buffer ProduceConsume Produce Rudder Controller RGRG R Gyroscope Value Empty Buffer Slot Resource(R G,R R,0) Resource(R R,R G,1) Exclusion(R G,R R ) Resource(R G,R R,0) + Resource(R R,R G,1) + Exclusion(R G,R R ) Invariant:

18. Generating Coarse-grain Solution Resource(R G,R R,0) + Resource(R R,R G,1) + Exclusion(R G,R R ) Invariant: Resource(R G,R R,0) R_in <= G_out (R_in <= G_out) && (G_in <= R_out + 1) && ((G_in == G_out) || (R_in == R_out)) Desugared Invariant: Resource(R R,R G,1) Exclusion(R G,R R ) G_in <= R_out + 1 (G_in == G_out) || (R_in == R_out) …producer out …consumer in

19. Generating Coarse-grain Solution G_in++ …invariant I holds here …want I to hold here Task: generate a condition B that ensures that I holds after counter increment. Step 1: generate weakest-precondition(G_in++,I) (R_in <= G_out) && (G_in <= R_out + 1) && ((G_in == G_out) || (R_in == R_out)) (R_in <= G_out) && (G_in+1 <= R_out + 1) && ((G_in+1 == G_out) || (R_in == R_out)) Substitute G_in+1 for G_in G_in++>

20. Generating Coarse-grain Solution Step 2: simplify using decision procedures 1.Convert to disjunctive normal form 2.Eliminate disjuncts that are can never be satisfied using decision procedures 3.Minimize remaining conjuncts using decision procedures Example: (R_in <= G_out) && (G_in+1 <= R_out+1) && (G_in+1 == G_out) || (R_in <= G_out) && (G_in+1 <= R_out+1) && (R_in == R_out) 1. (R_in <= G_out) && (G_in+1 <= R_out+1) && (R_in == R_out) 2. (G_in+1 <= R_out+1) && (R_in == R_out) 3.

21. Coarse-Grain Solution (skeleton) <await (G_in+1 <= R_out+1) && (R_in == R_out) -> G_in++> /* insert gyroscope value into buffer */ Gyroscope controller critical region: <await (R_in < G_out) && (G_in == G_out) -> R_in++> /* insert gyroscope value into buffer */ Rudder controller critical region:

22. Generating Fine-Grain Solution C1++> C2++> C3++> C4++> Cn++> Traditional Monitor Solution int C1, C2, …, Cn; …counter variables int cv1, cv2, …, cvn; …condition variables with an associated queue for each await Procedure Await1 () … Procedure Await2 () … Procedure Awaitn () … …… …procedure to implement each await

23. Generating Fine-grain Solution Use a single lock to protect access to counters Use a pattern called “specification notification” to implement await’s –One lock for each await statement –Ensures that separate waiting queues are maintained for each await

24. Compilation of S> public static boolean check$ () { synchronized (clusterCounterLock) { if ( ) { return true; } else return false; } public static void () { synchronized (condition$ ) { while (!check$ ()) { try { condition$.wait(); } catch (InterruptedException e) {} } /* add relevant notify calls */ } …grab lock for this await …if guard B is false …go to sleep …grab lock protecting counters …if guard is true …do increment …return true …else return false …notify awaits whose conditions may become true because of the current counter increment

25. Summarizing… UML Tools Synchronization Aspect Specification Tool Intermediate Representation Generator Solver/ Prover Course-grain solution Synchronization Aspect Back-end Bandera Analysis & Transformation Fine-grain solution Specialization Engine Bandera Safety Properties Liveness Properties Code Weaver Optimized Woven Code Invariant & Region tags Functional Core Code Templates (Java, C++, …) Template Instantiation Traditional Development Environment Functional Core Code (Java, C++, …) Finite State Models

26. Short-term goals (3-4 months) Add GUI to current prototype Generate solutions to a large collection of standard synchronization problems Hook in Bandera to check safety/liveness properties Examine SEABORNE target code to assess how much of synchronization can be expressed in terms of our patterns Generate CAN-based message passing fine- grain solutions (C with CAN library)

27. Medium-term goals (6-12 months) Extend global invariant approach to include real-time properties Integrate UML tools into front-end Use specialization to compress verification models

28. Long-term goals (1-2 years) Generate fine-grain solutions for other languages (C++, AspectJ, etc.) Consider other synchronization related aspects (distribution, coordinated error- handling, debugging) Extensions to the language of global invariants