Automatic Automatic Derivation, Integration, and Verification of Derivation, Integration, and Verification of Synchronization Aspects in Synchronization Aspects in Object-Oriented Design MethodsObject-Oriented Design Methods
Principal Investigators
Matt DwyerJohn HatcliffMasaaki MizunoMitch NielsenGurdip Singh
Department of Computing and Information Sciences
Kansas State University
http://www.cis.ksu.edu/santos
Collaborative Research at K-StateCollaborative 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)
Problem StatementProblem Statement:Card Reader
:Display :Key Pad
:ClientManager
:CashCounter
:TransManager
Card inserted (ID)Insert Card
Show request
Specify PIN code
PIN Code (PIN)
Ask for PIN code
Request PIN validationAsk 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.
Our ThemeOur Theme
…Focus on building core functional code (minus synchronization)
…Give formal high-level spec of synchronization behavior
…Correct synchronization code is synthesized andlinked in automatically
Goals of the ProjectGoals 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)
Global Invariant ApproachGlobal Invariant Approach
Readers Writer
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++
ImplicitW_in++
W_out++
Implicit
(R_in – R_out == 0 || W_in – W_out == 0)Invariant:
Global Invariant ApproachGlobal Invariant Approach
Readers Writer
Buffer
<await B -> C> …wait until B then execute C atomically<C> …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++>
<R_out++>
<await R_in–R_out == 0 && W_in-W_out == 0 -> W_in++>
<W_out++>
Called the “coarse-grain” solution
Global Invariant ApproachGlobal Invariant Approach
Readers Writer
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
Advantages of OurAdvantages of OurGlobal Invariant ApproachGlobal 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
Our ApproachOur Approach--- Invariant Patterns--- 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 kth thread to enter R1 and the kth thread to enter R2
meet and leave their respective regions together Barrier with information interchange… Complex Barrier…
Our ApproachOur Approach--- Invariant Patterns--- 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)
Our ApproachOur Approach--- Automatic Synthesis --- Automatic Synthesis
Both coarse-grain and fine-grain solutions are synthesized automatically
.java.java
.java .java
+ Invariant
Fine-grainJavaRepresentationGenerator
IntermediateRepresentationGenerator
PVS
.java+ guarded commands
.java
+
.java
Core code
Synchronizationaspect
Tool ArchitectureTool Architecture
UML Tools
SynchronizationAspectSpecificationTool
IntermediateRepresentationGenerator
Solver/Prover
Course-grainsolution
SynchronizationAspectBack-end
BanderaAnalysis &Transformation
Fine-grainsolution
Specialization EngineBandera
SafetyProperties
LivenessProperties
Code Weaver
OptimizedWoven Code
Invariant &Region tags
Functional CoreCode Templates
(Java, C++, …)
TemplateInstantiation
TraditionalDevelopmentEnvironment
Functional CoreCode
(Java, C++, …)
Finite StateModels
Example: Vessel Control Example: Vessel Control
Sensors Actuators
Engine Controller Rudder Controller
RudderSensor
RudderPump
Throttle Controller
Throttle
Fiber/TP Hub GPSOther Sensorsand Actuators
CAN Bus
…from Navy SEABORNE target vehicle documentation
Gyroscope/Rudder Sub-systemGyroscope/Rudder Sub-system
GyroscopeController
Buffer
RudderController
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
Use Cases and Critical RegionsUse Cases and Critical Regions
Gyroscope Controller Rudder 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: RG
Critical Region: RR
Identify segments (a) that must wait for some even to occur (b) segments that cause events waited for in (a)
Gyroscope/Rudder SynchronizationGyroscope/Rudder Synchronization
GyroscopeController
Buffer
Produce Consume
Consume Produce
RudderController
RG RR
Gyroscope Value
Empty Buffer Slot
Resource(RG,RR ,0)
Resource(RR,RG ,1)
Exclusion(RG,RR)
Resource(RG,RR ,0) + Resource(RR,RG ,1) + Exclusion(RG,RR) Invariant:
Generating Coarse-grain SolutionGenerating Coarse-grain Solution
Resource(RG,RR ,0) + Resource(RR,RG ,1) + Exclusion(RG,RR) Invariant:
Resource(RG,RR ,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(RR,RG ,1)
Exclusion(RG,RR)
G_in <= R_out + 1
(G_in == G_out) || (R_in == R_out)
…producer out
…consumer in
Generating Coarse-grain SolutionGenerating 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))
SubstituteG_in+1 forG_in
<await B -> G_in++>
Generating Coarse-grain SolutionGenerating Coarse-grain Solution
Step 2: simplify using decision procedures
1. Convert to disjunctive normal form2. Eliminate disjuncts that are can never be satisfied using decision procedures3. 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.
Coarse-Grain Solution (skeleton)Coarse-Grain Solution (skeleton)
<await (G_in+1 <= R_out+1) && (R_in == R_out) -> G_in++>
/* insert gyroscope value into buffer */
<G_out++>
Gyroscope controller critical region:
<await (R_in < G_out) && (G_in == G_out) -> R_in++>
/* insert gyroscope value into buffer */
<R_out++>
Rudder controller critical region:
Generating Fine-Grain SolutionGenerating Fine-Grain Solution
<await B1 -> C1++>
<await B2 -> C2++>
<await B3 -> C3++>
<await B4 -> C4++>
<await Bn -> 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
Generating Fine-grain SolutionGenerating 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
Compilation of Compilation of <<await B -> S>await B -> S>
public static boolean check$<aname>() { synchronized (clusterCounterLock) { if (<B>) { <S> return true; } else return false; }}
public static void <aname>() { synchronized (condition$<name>) { while (!check$<aname>()) { try { condition$<aname>.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
Summarizing…Summarizing…
UML Tools
SynchronizationAspectSpecificationTool
IntermediateRepresentationGenerator
Solver/Prover
Course-grainsolution
SynchronizationAspectBack-end
BanderaAnalysis &Transformation
Fine-grainsolution
Specialization EngineBandera
SafetyProperties
LivenessProperties
Code Weaver
OptimizedWoven Code
Invariant &Region tags
Functional CoreCode Templates
(Java, C++, …)
TemplateInstantiation
TraditionalDevelopmentEnvironment
Functional CoreCode
(Java, C++, …)
Finite StateModels
Short-term goals (3-4 months)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)
Medium-term goals (6-12 months)Medium-term goals (6-12 months)
Extend global invariant approach to include real-time properties
Integrate UML tools into front-endUse specialization to compress
verification models