automatic derivation and verification of synchronization aspects in object oriented systems gurdip...
TRANSCRIPT
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
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
Scenarios
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
When an operator becomes free
1. Call to the generated function
2. {connected to an external call} record the connection time and operator’s ID
When the operator hangs up
1. Call to the generated function
2. {external call has terminated} record the call termination time and log the record
When an external call arrives
1. Record the arrival time
2. Call to the generated function
3. {connected to an operator} record information for log
When 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
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
Subscription and filtering
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
Subscription and filtering
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
Subscription and filtering
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
…
Bold Stroke Components
XMLConfigurationSpecification
Configured Build
Synchronization specifications
- component behavior is modified by including control code in the components
Configurator
Development Methodology
…
Bold Stroke Components
Configured Build
Configurator
XMLConfigurationSpecification
Synchronization specifications
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