automatic derivation and verification of synchronization aspects in object oriented systems gurdip...

Automatic Derivation and Verification of Synchronization Aspects in Object

Oriented Systems

Gurdip Singh

Masaaki Mizuno

Kansas State University

This research was in supported in part by DARPA PCES Order K203/AFRL #F33615-00-C-3044 and NSF CRCD #EIA-9980321

Why aspect oriented Programming?

-“Code tangling”: * code for a requirement is spread through many classes; * cross-cutting * code for different requirements are tangled

-Programs are hard to maintain * modifying code for a specific requirement is not easy * redundancy

Aspect-Oriented Programming

- Solution: * separate software into functional code and aspect code

* Develop functional code independently

* Develop code for each aspect separately

* Weave functional code with aspect code

AOP

Ordinary Program

Functional code

Code for aspect 1

Code for aspect 2

Better structured program

Aspect-Oriented Programming

- Solution: * separate software into functional code and aspect code

* Develop functional code independently

* Develop code for each aspect separately

* Weave functional code with aspect code

- Untangles code, eliminates redundancy

- Code is easy to maintain and modify

- Customized versions of software

Contents Why aspect oriented methodology ? Synchronization * Is it an aspect ? * Why should we treat it as an aspect ? An aspect oriented methodology * Andrew’s Global Invariant Approach * UML-based methodology * Translation for Java shared memory programs * Pattern-based approach * Examples

Contents (contd) SyncGen Demonstration More Back-end translations: Lock-free translations,

CAN Synchronization in component-oriented embedded

software Bottom-up methodologies * COOL * Composition Filters * Synchronizers * Superimposition Wrap-up

Synchronization The importance of concurrent programming has

increased However, many programmers and designers are not

appropriately trained to write correct and efficient concurrent programs

Most OS textbooks teach ad-hoc techniques– Showing solutions in low-level synchronization

primitives for a small number of well-known problems, such as readers/writers and dining philosophers problems

– Such solutions do not generalize to complex real-life synchronization problems in various primitives

Reader: mx.p( ); rc := rc + 1; if rc = 1 then wrt.p( ); mx.v( ); reading mx.p( ); rc := rc – 1; if rc = 0 then wrt.v( ); mx.v( );

Writer: wrt.p( ); writing wrt.v( );

Readers/Writers with weak readers preference

W W R W

R R R

wrt

mx

Writer mx2.p( ); nw := nw + 1; if nw = 1 then r.p( ); mx2.v( ); w.p( ); writing w.v( ); mx2.p( ); nw := nw – 1; if nw = 0 then r.v( ); mx2.v( );

Reader mx3.p( ); r.p( ); mx1.p( ); rc := rc + 1; if rc = 1 then w.p( ); mx1.v( ); r.v( ); mx3.v( ); reading mx1.p( ); rc := rc – 1; if rc = 0 then w.v( ); mx1.v( );

Readers/writers with writers preference

Courtois et.al, CACM 1971

We need a more formal and structured approach to develop concurrent programs

The methodology must be easy to use

The resulting code must be efficient

The goals of our approach

Our methodology is

– based on global invariant approach,

– in the aspect oriented programming paradigm

– in the context of scenario based development methodologies (such as Rational Unified Process (RUP))

Outline (part1)

1. Andrews’ Global Invariant (GI) approach

2. Aspect-oriented programming

• Rational Unified Process (RUP)

3. Our concurrent program development methodology

4. Translations to find-grained synchronization code

• Java synchronized blocks

• Thread-pool model

5. Pattern-based approach

• Basic synchronization patterns and solution invariants

• Composition of patterns

• Applications of patterns

6. Evaluation and Conclusion

Greg Andrew’s Global Invariant (GI) approach

1. Specify a safety property of synchronization using a global invariant (GI)

e.g., readers/writers problem

Let nr be the number of readers currently reading

Let nw be the number of writers currently writing

Then, the GI may be

)1()00( nwnwnr

2. Mechanically derive a coarse-grained solution from the invariant

Coarse grained solution links GI to the program in high-level synchronization construct

<S > <await TRUE

e.g., nr must be incremented when a thread starts reading and decremented when a thread completes reading.

<await B S >

< await nrnw 0 >}{GI }{GI

S

),( GInrwpBGI

reading

}{}0{ GInrnwGI

3. Mechanically translate the coarse-grained solution to various fine-grained synchronization code in Semaphores, Monitors, Active Monitors (message passing), Java Synchronized Blocks, Thread-Pool Model, etc.

Each translation is guaranteed to preserve GI; therefore, the resulting code satisfies the safety property

Monitor = class + mutex + condition

lock

c1.wait( ); …

f( ) g( )

c1

c2

x, y, z

c1.signal( );

c2.wait( );

e.g., Monitor

e.g., Monitor

< await ii SB

while not Bi do Ci.wait( ); Si;

< Sj >

Sj

Add Ck.signal( ) or Ck.signalAll( ) if execution of Si can potentially change the value of Bk to TRUE

Aspect Oriented Programming

Properties to be implemented are classified into

1. Component which can be clearly encapsulated in a generalized procedure (i.e., object, method, procedure, etc)

2. Aspect which cannot be clearly encapsulated in a general procedure (i.e., synchronization, distribution, etc)

This approach reduces complexity and code-tangling by separating cross-cutting concerns.

We use

• scenario based development methodology (i.e., RUP) for component code development

•GI approach for synchronization aspect code development

Rational Unified Process

Component code

Actors

Use-cases

Classes

Use-case realizations

Use-case model

(What)

Analysis/design models

(How)

implementation

Rational Unified Process (RUP) Use-case realizations (scenarios)

Classes/objects

Need to wait

Automatic Call Distribution System

Threads

A scenario is translated into a sequence of method calls (sequential program)– One program for the operator scenario– Another for the external call scenario

Instantiate one thread for each operator phone and external line

An advantage of concurrent programs:

each activity can be written as a sequential program

Synchronization regions and clusters

Synchronization region in use-case realization:– a thread waits for some event to occur or some state to

hold– a thread may trigger an event or change a state for which

a thread in some synchronization region is waiting Cluster: Partition of synchronization regions based on their

reference relations

Rational Unified Process

waitwakeup

wait

wakeup

with synchronization aspect code development

Identifying synchronization regions and clusters

Our development methodology

Fine-grained code

Component codeActors

Use-cases

Classes

Scenarios

Global invariants (patterns)

Coarse-grained solution

Complete code

RUP

Synchronization aspect code development

In scenarios, identify synchronization regions in which synchronization is required

Specify a global invariant for each cluster

Scenarios

When an external call arrives

1. Record the arrival time

2. Wait until an operator becomes ready

3. {connected to an operator} record information for log

When external call terminates

1. {external call has terminated} wait until the operator hangs up

When an operator becomes free

1. Wait until an external call arrives

2. {connected to an external call} record the connection time and operator’s ID

When the operator hangs up

1. {Operator has hung up} wait until the external call terminates

2. {external call has terminated} record the call termination time and log the record



2. Wait until an operator becomes ready



1. {external call has terminated} wait until the operator hangs up

Scenarios


1. Wait until an external call arrives



1. {Operator has hung up} wait until the external call terminates



1. Call to the generated function











Scenarios

Component code a.fun( ); y := y + 3; . . M.eneter( );

buf [head] := x; head := (head+1)%N . .

M.exit( ); . . x := x + 2; m.g( );

scenario

Code Weaving Process

Region Renter( );

exit( );

Aspect code in instance M

Anonymous and Specific Synchronization

• Anonymous Synchronization: among anonymous threads (i.e., any thread can synchronize with any other threads in the cluster)

A single instance of fine-grained solution (synchronization code) is created and all the threads execute in the instance

• Specific Synchronization: among a set of specific threads (called a group)

multiple instances of the fine-grained solution are created, one for each group; all threads in the same group use the instance assigned to it.

anonymous ….group1 group2 groupN

Translation to Java Synchronized Blocks

Review of Java Synchronization Primitives

• Object has a lock and one condition variable

a. synchronized(obj) { critical section. may call obj.wait( ), obj.notify( ), obj.notifyAll( ) }

b. type method(…) {

synchronized (this) { body of method }

}

is equivalent to

synchronized type method(…) { body of method }

• All threads in the same cluster sleep in the same condition variable

lock

Condition

wait( );notify( );

notifyAll( );

lock

c1.wait( );

Condition

Condition

c1

c2

c1.notify( );

Specific Notification (Cargill, 1996)Java monitor

c2.wait( );

synchronized methods

Our Translation to Java Synchronized Blocks

1. For each cluster, define one java class

2. For < await Bi → S i >

1. private Object oi = new Object( );2. pubic void methodi( ) { synchronized (o i) { while (! checkBi( )) try {oi.wait( ); } catch (InterruptedException e) { } } }3. private synchronized Boolean checkB i ( ) { if (B i) { S i; return true; } else return false; }

3. For <Sj >

1. public void method j ( ) { synchronized (this) { Sj; } }

4. If execution of Si (or Sj) potentially change some Bk to ture, add

1. synchronized (ok) {ok.notify( );}, or

2. synchronized (ok) {ok.notifyAll( ); }

Correctness:

1. Bi; Si; and Sj are all executed in synchronized (this) blocks

2. Nesting level of synchronized blocks is at most two; the order is always block on ok being outside and block on this inside.

3. oi.wait( ); is executed within a sole synchronized block on oi

4. Checking Bi and execution of oi.wait( ) are protected inside synchronized block on oi No missed notification.

Translation to Thread-Pool Model

Thread-Pool model

• It is widely used in web-servers and embedded systems

• The system maintains a pool (pools) of job threads. When a request arrives, it is passed to a free job thread in the pool

• When an execution needs to be blocked, synchronization code releases and returns the executing thread to the thread pool, rather than blocking the thread.

This is not a context switch, rather a return from a function and a new call.

• It is easy to remove blocked jobs from the system since no threads are associated with the jobs

Job objects and thread pools

GenericJob

execute( );

1. A job object inherits GenericJob and implements execute( )

2. ThreadPool maintains jobQueue (queue of GenericJob) and provides the two operations

void addJob(GenericJob job) {<jobQueue.enqueue(job)>}

GenericJob getJob( ) {

<await (not jobQueue.isEmpty( )) → return jobQueue.dequeu( )>

}

3. Job threads execute the following codewhlie(true){(threadPool.getJob( )).execute( );}

jobQueue

blocked threads at <await>

Translation Algorithm

1. Declare one monitor for each cluster.2. For each < await Bi →Si >,

• declare queuei (queue of GenericJob)• declare gMethodi

boolean gMethodi(GenericJob job) { if (not Bi) {queuei.enqueue(job); return false; } Si; return true; }

3. For each < Sj >,• declare ngMethodj

void ngMethodj ( ) { Sj; }

4. Add singalk() after Si wherever necessaryvoid signalk( ) { while ((not queuek.isEmpty( )) ∧Bi) { Si; threadPool.addJob(queuei.dequeue( )); } }

Job objects

1. Inherit (or implement) GenericJob and override execute( )

2. Devide the scenario into phases by each appearance of

<await> statement

3. Body of execute( ) is

switch (phase) {

case 0:

sequential code derived for phase 0 section of the scenario

if (not synchObject.gMethod1(this))_{phase = 1; return;}

case 1:

….

}

Performance Evaluation (Jacobi Iteration 1000x1000)

Performance of Thread-Per-Job Model vs Thread-Pool Model

0

50000

100000

150000

200000

250000

0 200 400 600 800 1000 1200Jobs

Tim

e(m

sec)

Thread-Per-Job Thread-Pool (10 threads)

Linux running on MHz Xeon processors4504

• One possible drawback of GI approach is the difficulty to identify an appropriate global invariant that correctly and accurately implies the safety property of the synchronization requirement.

• To cope with this problem, we have developed a set of useful synchronization patterns and their solution invariants.

Synchronization patterns

NOutIn RR

Bound(R, n): at most n threads can be in R

Region R

InR

OutR

K_MuTex(R1, R2, …, Rn, k): at most k threads can be in (any) regions

R1 R2 Rn…

kOutIn ini i )(1

Exclusion(R1, R2, …, Rn): threads can be in at most one region out of n regions

R1 R2 Rn…

))0((1 iiCi)n(n,CombC OutIn

e.g.,

))0()0(( 2211 OutInOutIn

))0()0(( 3311 OutInOutIn))0()0(( 3322 OutInOutIn

3n Comb(3,2) = {(1,2), (1,3), (2,3)}

Resource((RP , NP), (RC, NC), n): Initially, there are n resource items in the resource pool.

•When a thread executes RP , it produces NP resource items.

•When a thread executes RC, it consumes NC items. If there are less than NC items in the pool, a thread trying to enter RC waits until there are at least NC items in the pool

CPPC NnNOutIn /)((

RC , NCRP , NP n

…R1, N1R2, N2 Rn, Nn

Barrier((R1,N1), (R2,N2), …, (Rn,Nn)): all Ni threads in Ri (1 i n) meet, form a group, and leave the respective regions together

)))/((( 11 ijjinjni NNInOut

e.g., 3,2,2 21 NNn

)2)3/(()2)2/(( 2111 InOutInOut

)3)3/(()3)2/(( 2212 InOutInOut

AsymBarrier: Asymmetric version of Barrier, where entries of threads to a set of regions trigger departures of threads from a set of regions

R1, 2 R2, 3 4,3R

e.g., )4)3/(()4)2/(( 2313 InOutInOut

)4)4/(( 33 InOut

Composition of patterns

1. Composition of invariants

• Producers/Consumers with n-bounded buffer

• Readers/Writers problem

))0()0(()1( RRWWWW OutInOutInOutIn

Bound(Rw, 1) ∧ Exclusion(Rw, RR)

Resource((RP ,1),(RC ,1),0) ∧Resource((RC ,1),(RP ,1),n) ∧

Bound(RP ,1) ∧Bound(RC ,1)

• Search, insert, and delete: Three kinds of threads share access to a singly linked list: searchers, inserters, and deleters

•Searchers can execute concurrently with other searchers

•Inserters must be mutually exclusive with other inserters

•One inserter can proceed in parallel with multiple searchers

•At most one deleter can access the list and must be mutually exclusive with searchers and inserters

Bound(RI ,1) ∧Bound(RD ,1) ∧Exclusion(RD , RS) ∧

Exclusion(RD , RI)

2. Composition of sub-clusters

• Readers/Writers problem

Exclusion

RR RW

Bound

RRRW

Bound

Exclusion

(1) (2)

• Information Exchanging Barrier

((R1 , N1), (R2 , N2), …(RN , NN)

Bound (R1 , N1) Bound (R2 , N2) Bound (RN , NN)

(R1 , N1)

(R1 , N1)

(R2 , N2)

(R2 , N2)

(RN , NN)

(RN , NN)

write write write

read read read…..

…..

Barrier

Barrier

Observation

1. When multi-stage synchronization is needed, composition of sub-clusters must be used (e.g., Information Exchanging Barrier)

2. Composition of invariants may be viewed as a special case of composition of sub-clusters, in which all In counters of the sub-regions are incremented atomically, and so are the Out counters.

• When the atomicity is not required, synchronization using composition of global invariants may be realized by composition of sub-clusters

3. Composition of sub-clusters has an advantage; we can construct a library of fine-grained implementation of the basic patterns.

Examples

1. (A) Roller Coaster Ride Problem

There are n passengers and one roller coaster car.

• The car holds C passengers and can go around the track only when it is full. The car takes T seconds to go around the track.

• The passengers repeatedly wait to take rides in the car. After getting a ride, each passenger wanders around the amusement park for a random amount of time before returning to the coaster for another ride.

Passenger thread[P1] Wait until his/her turn comes

and get on the car

[P2] Wait until the car goes around and stops

[P3] Get off the car

[P4] Wander around the amusement park

Scenarios for the coaster problem

Car Thread[C1] Wait until C passengers have

gotten on the car

[C2] Go around the track (elapse T seconds)

[C3] Stop and have the passengers get off the car

[C4] Wait until all C passengers have left

Synchronization regions and appropriate patterns

Steps [C1] and [P1]: Barrier((RC1, 1), (RP1, C))

Steps [C3] and [P2]: AsymBarrier([(RC3,1)],[(RP2,C)])

Steps [C4] and [P3]: AsymBarrier([(RP3,C)], [(RC4,1)])

C3

C2 P4

Coaster Thread Passenger Thread

P2

P3C4

C1 P1 RC11

RC31

RC41

RP1C

RP2C

RP3C

Barrier

AsymBarrier

AsymBarrier

1. (B) Multiple Coaster Cars Problem

Generalize the previous problem to contain M cars. For passenger safety, only one car at a time is permitted to go around the track

C2 P4

Coaster Thread Passenger Thread

P2

P3C4

P1

RC41

C1 RC11

RP1C

RP3C

C3 RC31

RP2C

Info Exchanging Barrier

SpecificAsymBarrier

Rc2Bound

Specific

AsymBarrier

2. Hungry Birds Problem

Given are N baby birds and one parent bird. There is a dish which initially contains F portions of food.

• Each baby bird repeatedly fetches one portion of food at a time, eats it, sleeps for a while, and then comes back to eat. If the dish becomes empty when a baby bird picks up food, he awakens the parent bird.

• When the parent bird wakes up, it finds F portions of food, puts them in the dish, and goes back to sleep.

Parent Bird

[P1] wait until a baby bird finds the dish empty

[P2] find F portions of food and put them in the dish

[P3] inform the waiting baby bird

Baby Bird[B1] sleep for a while

[B2] check if the dish is (was) empty

(n = 0)

[B3] if so, wait until parent places

F portions of food in the dish

[B4] set n := F

[B5] pick up one portion of food in

the dish (n := n – 1)

[B6] check whether the dish

becomes empty (n = 0)

[B7] if so, inform parent

[B8] eat food

Scenarios

P1

P3

B1

P2

AsymBarrier

Bound

AsymBarrier

parent baby

B2

B3

B4B5B6

B7

B8

3. Atomic Broadcasting

One producer and n consumers share a buffer. The producer deposits messages into the buffer, and consumers fetch them. Every message deposited by the producer has to be fetched by all n consumers before the producer can deposit another message into the buffer. The producer should not be blocked by consumers until right before it actually deposits a message.

Scenarios

Producer

[P1] wait until n consumers have read the message from the buffer (first time, this step is skipped: staggering property)

[P2] write a message

[P3] notify n consumers

Consumer

[C1] wait until the producer writes a message to the buffer

[C2] read the message

[C3] notify the producer

Cluster [C3, P1]: staggered AsymBarrier

)1( 311 iCPni InOut

Cluster [P3, C1]: AsymBarrier

)( 311 PiCni InOut

Write

Read

….

Consumer n Consumer 2 Consumer 1 Producer

Evaluation

1 (most difficult)

2 3 4 5 (easiest) Ave.

Ad-hoc 6 7 10 2 0 2.3

GI

no patterns

1 2 8 11 2 3.5

GI with patterns

0 1 3 7 13 4.3

B. Exams

Exam 1 (covered ad-hoc, GI without patterns): average 62.1

Final Exam (covered GI with patterns): average 87.2

CIS 720 (Advanced Operating Systems) Fall 2001

Total 35 students (mostly graduate students)

A. Questionnaire

Conclusion (part1)

1. Presented a methodology to develop concurrent programs in a scenario-based development approach (such as RUP), in the aspect oriented programming paradigm.

• Structured, high-level, based on theoretical foundation provided by Global Invariant approach

• Aspect synchronization codes are obtained mechanically from invariants

2. Presented translation algorithms for Java synchronized blocks and thread-pool model

3. Presented a set of synchronization patterns and their solution invariants

• Demonstrated the effectiveness by applying them to solve various synchronization problems

Tool 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

Verification

Wait until gyroscope value is in buffer

Read value from buffer

Actuate rudder based on value

Read a value from the

gyroscopeWait until the

buffer becomes empty

Write a new value in the buffer

Use Cases

Unsynchronized components

Named Synchronization Points/Regions

Automatic verification of critical safety and liveness properties of woven embedded code

Resource(RG,RR ,0) + Resource(RR,RG ,1)

+ Exclusion(RG,RR)

Synchronization Specification

… built on top of Bandera

System Model

Core Code Model

Sync Code Model

Bandera

VerificationWait until gyroscope value is in buffer

Read value from buffer

Actuate rudder based on value

Read a value from the

gyroscopeWait until the

buffer becomes empty

Write a new value in the buffer

Use Cases

Unsynchronized components

Named Synchronization Points/Regions

IV. Automatic verification of critical safety and liveness properties of woven embedded code

Resource(RG,RR ,0) + Resource(RR,RG ,1)

+ Exclusion(RG,RR)

Synchronization Specification

System Model

Bandera

Core Code Model

Sync Spec Model

Derived fromspecification

Derived fromspecification

RW State space: Full Java: 1,559,250 Hybrid: 534

C w/CAN

Message Passing

C w/CAN

Message Passing

C++ Posix ThreadsC++ Posix Threads

Generating Fine-Grain Solution

<await B1 -> C1++>

<await B2 -> C2++>

<await B3 -> C3++>

<await B4 -> C4++>

<await Bn -> Cn++>

Java Java

C++ w/ CORBA

Event Channel

C++ w/ CORBA

Event Channel

Back endTranslators

Concurrent Entering in Shared Memory Algorithms

- Concurrent Entering- Proposed by Joung [1998], Hadzilacos [2001]

* If there does not exist a conflicting request, then a request must not be delayed due to any other request.

- Algorithms for concurrent entering in Group Exclusion [Joung88, Hadzilacos2001]

Concurrent Entering Shared Memory algorithms

Highly concurrent algorithm using fetch-and-add instruction [Singh02] Algorithm using atomic read/write variables

lock()

unlock()

Path without waiting for other requests

wait

Traditional monitor solution

Message Passing Solutions

P1,…,Pn : processes/components

R1,…,Rm: regions

St1,…,Stn: await statements

Stx: <await(Condx)ctx++>

Message passing system

Asynchronous message passing systems

Message passing system

Extensions of Lamport’salgorithm and Ricart and Agarwala’s algorithm

Controller Area Networks

Controller Area Network

Active Monitor

Centralized solution

proxies

Controller Area Networks

Controller Area Network

Decentralized solution

Component-based Programming

Integration Infrastructure

Boeing Bold Stroke Platform

Radar

Weapons

Nav Sensors

WeaponManagement

Data Links

Many Computers

Many Computers

Multiple BusesMultiple Buses

Constrained Tactical LinksConstrained

Tactical Links

O(106) Lines of Code

O(106) Lines of CodeHard & Soft

Real-TimeHard & Soft Real-Time

Periodic & Aperiodic

Periodic & Aperiodic

Multiple Safety Criticalities

Multiple Safety Criticalities

Information Security

Information Security

Focus Domain

MissionComputer

VehicleMgmt

COTSCOTS

Control-Push Data-Pull Structure

1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device.2. Logical GPS publishes DATA_AVAILABLE event

3. Airframe component fetches GPS data by calling GPS GetData method4. Airframe updates its position data and publishes DATA_AVAILABLE event5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method6. NavDisplay updates the physical display

System Architecture

ORB

Event Service

Event propagation

Data Service

Data propagation

Event Service

Sensor1

Sensor2

Sensor3 Actuator2

Actuator1

Controller

Actuator3

- One-way communication- Anonymous communicationEvent Service

Existing Development Methodology

…

Bold Stroke Components

XMLConfigurationSpecification

Configured Build

Synchronization specifications

- component behavior is modified by including control code in the components

Configurator

Cadena

CCM IDL3 level component development

High-level Connection specification

Analysis and QoSAspect Synthesis

<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

XML Configurator Info

Cadena

Integrated Development Environment

High-level Specification

Language

CCM Interface Definition Language

RT Aspect SpecsState

TransitionsSystem

Configuration

Eclipse Plug-In

ModalSP

Three Synchronized Views

ScenarioDescriptionScenarioDescription

SingleInternal

Representation

SpreadsheetView

SpreadsheetView

Graphical View

Graphical View

Textual View

Textual View

Textual View

Graphical View

Spreadsheet View

…ports for component type

…ports for component type

…port types

…port types

…port connections…port connections

…distribution sites

…distribution sites

…rate group

…rate group

RT AttributesRT Attributes

Aspect SynthesisDependency-driven rate assignment to event handlers

5Hz5Hz

5Hz5Hz

5Hz5Hz

20Hz20Hz

1Hz1Hz20Hz20Hz

20Hz20Hz

20Hz20Hz

20Hz20Hz

20Hz20Hz

tacticalDisplay1

tacticalDisplay2

hud

navDisplayairframe

tacticalSteering

radar

tracksensor1

tracksensor2

tracksensor3

tracksensor4

track1track2track3track4track5track6track7track8track9

track10

radar1

gps

coherent

Both must be on at the same time

Mode 1: read from track1,2,4Mode 2: read from track 1,…,10

dynamiccorrelation

atomic

20hz

Specifying Synchronization

Specifying Synchronization

- e.published: number of events of type e published so far

- e.notified : number of notifications for event e pushed so far

- C.mode: mode of component C

- invariant: assertion over publish, notified, mode variables

-e1.notified <= e2.notified <= e1.notified + 1 * regulates the flow of notifications of e1 and e2 to a component so that these notifications alternate

Event-driven system: Components react to events

Supplier Proxies

Dispatching module

Consumer Proxies

Event correlation

Subscription and filtering

Supplier

Consumer

Consumer

Consumer

Tao’s Real Time Event Channel

- Filtering and correlation is on per-consumer basis

Supplier Proxies

Dispatching module

Consumer Proxies

Event correlation


Event Distribution and Coordination Service

SynchModule

- Synch_Module can observe the flow of events and control it

derived from the invariant

Supplier Proxies

Dispatching module

Consumer Proxies

Event correlation


New Filtering mechanisms

Supplier

Consumer

Consumer

Consumer

SynchModule

Update state

Synch_event are redirected to the Synch_Module

Notifications for Synch_notify events are redirected to the Synch_Module

0/1

0/1

Supplier Proxies

Dispatching module

Consumer Proxies

Event correlation


Condition Event

Supplier

Consumer

Consumer

Consumer

SynchModule

Update state

Condition events

Synch Code generation

Event Service

ScenarioSpecification

BMDeviceMonolithicImpl

BMDeviceCCM(context)

BMDeviceMonolithicWrapper

CCMObjectImplHomeCCM

Configured Event Service

Synch. Specification

Synch_Module

Existing Development Methodology

…



Configured Build


- component behavior is modified by including control code in the components

Configurator

Development Methodology

…


Configured Build

Configurator



SynchModule

-Different synchronization specifications result in different Synch_Module

Related Work: - Top down approach vs Bottom-up approach

- Complimentary approaches

Bottom-up Approach Cool Synchronizers Composition filters Superimposition

Cool: Coordination Aspect Language

* selfexclusive

* mutexclusive

-Based on AspectJ [C. Lopes and G. Kiczales 1997]- Coordinator: coordinates one or more classes

* condition variables

Bounded Buffer in Java

class BoundedBuffer { Object[] array; int putPtr = 0, takePtr = 0; int usedSlots = 0; BoundedBuffer(int capacity){ array = new Object[capacity]; }

Functional codeBoundedBuffer {public void push (Object o) { array[putPtr] = o; putPtr = (putPtr+1)%array.length; usedSlots++; }public Object pop() { Object old = array[takePtr]; array[takePtr] = null; takePtr = (takePtr+1)%array.length; usedSlots--; return old; }}

Tanglingsynchronized void push(Object o) { while (usedSlots == array.length) { try { wait(); } catch (InterruptedException e) {}; } array[putPtr] = o; putPtr = (putPtr +1 ) % array.length; if (usedSlots==0) notifyall(); usedSlots++; if (usedSlots++==0) notifyall();}

Coordinatorcoordinator BoundedStackCoord : BoundedStack { selfexclusive {pop, push} mutexlcusive {pop, push} cond boolean full= false, empty= true;

push : requires !full; on exit { if (sp == Max) full=true;) if (sp == 1) empty = false; } pop: requires !empty; on exit { if (sp == 0) empty =true; if (sp == Max – 1) full = false }}

Implementation Model

Coordinator

Object

1

6

5432

Synchronizers Frolund and Agha [1993] Synchronizers observe messages

flowing between actors Maintains local state that is changed

based on the observations May delay or reorder messages

atomicity

disabling enabling

• message patterns• constraints

Synchronizers constraining messages to objects

AllocationPolicy(adm1, adm2, max) { init prev = 0; prev>= max disable (adm1.request or adm2.request) (adm1.request or adm2.request) updates prev := prev + 1, (adm1.release or adm2.release) updates prev := prev – 1,}

Synchronizer for allocation policy for two objects adm1 and adm2

VendingMachine(accepter,applies,bananas, apple_price,banana_price){ init amount := 0; amount < apple_price disables apples.open, amount < banana_price disables banana.open, accepter.insert(v) updates amount := amount + v, (accepter.refund or apples.open or bananas.open) updates amount := 0 }

Vending machine synchronizer

Composition Filters [AT98]

class SyncStack interface { : : inputfilters sync: Wait= {Nonempty=>pop, True=>*\pop} };

specifies synchronization constraints

-Filters are used to block, buffer and reorder methods

Superimposition [L. Bouge 88][Chandy & Misra 88] Superimpose control computation on some

basic computation Basic computation: a set of guarded

commands Control computation: a set of guarded

command that may access variables of basic computation and may delay the basic computation

Merged protocol: *[ Bguard1 /\ Cguard1 a1:<Bcompute1; Ccompute1 > [] Bguard2 a2:<Bcompute2> [] Bguard3 /\ Cguard3 a3:<Bcompute3; Ccompute3> : : }

Control protocol: *[ Cguard1 a1:< Ccompute1> [] Cguard3 a3:< Ccompute3> [] : : ]

Basic computation protocol: *[ Bguard1 a1:< Bcompute1> [] Bguard2 a2:< Bcompute2> [] Bguard3 a3:<Bcompute3> : ]

Bi-directionaldata transfer

Flow control

Token-passing

Protocol Composition

Conclusion Aspect oriented approach to

synchronization SyncGen Complimentary to bottom-up approach Several back-end translations

automatic derivation and verification of synchronization aspects in object oriented systems gurdip...

Documents