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 InvestigatorsMatt 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 requestSpecify 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 ApproachReaders 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 ApproachReaders 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 ApproachReaders 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

+

.javaCore 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 GPS Other 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 SolutionResource(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

Long-term goals (1-2 years)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