Title: Automatic Derivation and Verification of Synchronization Aspects in Object Oriented Systems
1Automatic 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
2Why 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
3Aspect-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
4AOP
Ordinary Program
Better structured program
5Aspect-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
6Contents
- Why aspect oriented methodology ?
- Synchronization
- Is it an aspect ?
- Why should we treat it as an
aspect ? - An aspect oriented methodology
- Andrews Global Invariant Approach
- UML-based methodology
- Translation for Java shared memory
programs - Pattern-based approach
- Examples
7Contents (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
8Synchronization
- 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
9Readers/Writers with weak readers preference
wrt
R R R
mx
10Readers/writers with writers preference
Courtois et.al, CACM 1971
11The goals of our approach
- 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
- 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))
12Outline (part1)
- Andrews Global Invariant (GI) approach
- Aspect-oriented programming
- Rational Unified Process (RUP)
- Our concurrent program development methodology
- Translations to find-grained synchronization code
- Java synchronized blocks
- Thread-pool model
- Pattern-based approach
- Basic synchronization patterns and solution
invariants - Composition of patterns
- Applications of patterns
- Evaluation and Conclusion
13Greg Andrews Global Invariant (GI) approach
- 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
14- Mechanically derive a coarse-grained solution
from the invariant
- Coarse grained solution links GI to the program
in high-level synchronization construct -
- ltS gt ltawait TRUE
- e.g., nr must be incremented when a thread starts
reading and decremented when a thread completes
reading.
reading
15- 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
16e.g., Monitor
Monitor class mutex condition
17e.g., Monitor
lt await
18Aspect Oriented Programming
- Properties to be implemented are classified into
- Component which can be clearly encapsulated in a
generalized procedure (i.e., object, method,
procedure, etc) - 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
19Rational Unified Process
Use-case model (What)
Analysis/design models (How)
implementation
20Rational Unified Process (RUP)
Use-case realizations (scenarios)
Classes/objects
21Automatic Call Distribution System
Need to wait
22Threads
- 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
23Synchronization 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
24Rational Unified Process
with synchronization aspect code development
wakeup
wait
wait
wakeup
Identifying synchronization regions and clusters
25Our development methodology
26Scenarios
- When an operator becomes free
- Wait until an external call arrives
- connected to an external call record the
connection time and operators ID - When the operator hangs up
- Operator has hung up wait until the external
call terminates - external call has terminated record the call
termination time and log the record
- When an external call arrives
- Record the arrival time
- Wait until an operator becomes ready
- connected to an operator record information for
log - When external call terminates
- external call has terminated wait until the
operator hangs up
27Scenarios
- When an operator becomes free
- Wait until an external call arrives
- connected to an external call record the
connection time and operators ID - When the operator hangs up
- Operator has hung up wait until the external
call terminates - external call has terminated record the call
termination time and log the record
- When an external call arrives
- Record the arrival time
- Wait until an operator becomes ready
- connected to an operator record information for
log - When external call terminates
- external call has terminated wait until the
operator hangs up
28Scenarios
- When an operator becomes free
- Call to the generated function
- connected to an external call record the
connection time and operators ID - When the operator hangs up
- Call to the generated function
- external call has terminated record the call
termination time and log the record
- When an external call arrives
- Record the arrival time
- Call to the generated function
- connected to an operator record information for
log - When external call terminates
- Call to the generated function
29Code Weaving Process
Component code a.fun( ) y y 3
. . M.eneter( ) buf head
x head (head1)N . .
M.exit( ) . . x
x 2 m.g( )
scenario
Aspect code in instance M
Region R
enter( )
exit( )
30Anonymous and Specific Synchronization
.
anonymous
group2
group1
groupN
31Translation to Java Synchronized Blocks
- Review of Java Synchronization Primitives
- Object has a lock and one condition variable
- All threads in the same cluster sleep in the
same condition variable
32Java monitor
Specific Notification (Cargill, 1996)
synchronized methods
lock
lock
notify( )
c1.notify( )
wait( )
c1.wait( )
notifyAll( )
c2.wait( )
c1
Condition
Condition
c2
Condition
33Our Translation to Java Synchronized Blocks
- For each cluster, define one java class
- For lt await Bi ? S i gt
- private Object oi new Object( )
- pubic void methodi( )
- synchronized (o i)
- while (! checkBi( ))
- try oi.wait( ) catch
(InterruptedException e) -
-
- private synchronized Boolean checkB i ( )
- if (B i) S i return true
- else return false
-
34- For ltSj gt
- public void method j ( )
- synchronized (this) Sj
-
- If execution of Si (or Sj) potentially change
some Bk to ture, add - synchronized (ok) ok.notify( ), or
- synchronized (ok) ok.notifyAll( )
- Correctness
- Bi Si and Sj are all executed in synchronized
(this) blocks - Nesting level of synchronized blocks is at most
two the order is always block on ok being
outside and block on this inside. - oi.wait( ) is executed within a sole
synchronized block on oi - Checking Bi and execution of oi.wait( ) are
protected inside synchronized block on oi
No missed notification.
35Translation 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
36Job objects and thread pools
- A job object inherits GenericJob and implements
execute( ) - ThreadPool maintains jobQueue (queue of
GenericJob) and provides the two operations - void addJob(GenericJob job) ltjobQueue.enqueue(job
)gt - GenericJob getJob( )
- ltawait (not jobQueue.isEmpty( )) ?
return jobQueue.dequeu( )gt -
- Job threads execute the following code
- whlie(true)(threadPool.getJob( )).execute( )
jobQueue
blocked threads at ltawaitgt
37Translation Algorithm
38(No Transcript)
39Performance Evaluation (Jacobi Iteration
1000x1000)
40Synchronization patterns
- 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.
41- Bound(R, n) at most n threads can be in R
InR
OutR
42- K_MuTex(R1, R2, , Rn, k) at most k threads can
be in (any) regions
43- Exclusion(R1, R2, , Rn) threads can be in at
most one region out of n regions
44 - 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
45- 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
46- AsymBarrier Asymmetric version of Barrier, where
entries of threads to a set of regions trigger
departures of threads from a set of regions
47Composition of patterns
1. Composition of invariants
- Producers/Consumers with n-bounded buffer
Resource((RP ,1),(RC ,1),0) ?Resource((RC ,1),(RP
,1),n) ? Bound(RP ,1) ?Bound(RC ,1)
48- 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)
492. Composition of sub-clusters
Bound
Bound
RR
RW
RW
RR
Exclusion
Exclusion
(1)
(2)
50- Information Exchanging Barrier
- ((R1 , N1), (R2 , N2), (RN , NN)
Bound (R1 , N1)
Bound (R2 , N2)
Bound (RN , NN)
write
write
..
write
Barrier
(R1 , N1)
(R2 , N2)
(RN , NN)
..
read
read
read
Barrier
(R1 , N1)
(R2 , N2)
(RN , NN)
51Observation
- When multi-stage synchronization is needed,
composition of sub-clusters must be used (e.g.,
Information Exchanging Barrier) - 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 - Composition of sub-clusters has an advantage we
can construct a library of fine-grained
implementation of the basic patterns.
52Examples
- (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.
53Scenarios for the coaster problem
- 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
- 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))
54 Coaster Thread Passenger Thread
C1
P1
RC1 1
RP1 C
Barrier
C2
P4
RC3 1
RP2 C
C3
P2
AsymBarrier
P3
C4
RC4 1
RP3 C
AsymBarrier
55- (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
56 Coaster Thread Passenger
Thread
Info Exchanging Barrier
P1
C2
Rc2
P4
Bound
P2
Specific AsymBarrier
P3
C4
RC4 1
RP3 C
Specific AsymBarrier
57 Coaster Thread Passenger
Thread
Info Exchanging Barrier
P1
Bound
C2
P4
P2
Specific AsymBarrier
P3
C4
RC4 1
RP3 C
Specific AsymBarrier
58- 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.
59Scenarios
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
60parent
baby
B1
Bound
B2
P1
B3
AsymBarrier
B4
B5
P2
B6
AsymBarrier
B7
P3
B8
613. 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.
62Scenarios
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
63(No Transcript)
64Evaluation
CIS 720 (Advanced Operating Systems) Fall 2001
Total 35 students (mostly graduate students) A.
Questionnaire
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
65Conclusion (part1)
- 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 - Presented translation algorithms for Java
synchronized blocks and thread-pool model - Presented a set of synchronization patterns and
their solution invariants - Demonstrated the effectiveness by applying them
to solve various synchronization problems
66Tool Architecture
67Verification
Bandera
Automatic verification of critical safety and
liveness properties of woven embedded code
built on top of Bandera
68Verification
Bandera
IV. Automatic verification of critical safety and
liveness properties of woven embedded code
RW State space Full Java 1,559,250
Hybrid 534
69Generating Fine-Grain Solution
Java
ltawait B1 -gt C1gt
C Posix Threads
ltawait B2 -gt C2gt
C w/ CORBA Event Channel
ltawait B3 -gt C3gt
C w/ CAN Message Passing
ltawait B4 -gt C4gt
ltawait Bn -gt Cngt
Back end Translators
70Concurrent 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
71Concurrent Entering Shared Memory algorithms
lock()
unlock()
Traditional monitor solution
- Highly concurrent algorithm using fetch-and-add
instruction Singh02 - Algorithm using atomic read/write variables
72Message Passing Solutions
P1,,Pn processes/components
R1,,Rm regions
St1,,Stn await statements
Stx ltawait(Condx)?ctxgt
Message passing system
73Asynchronous message passing systems
Extensions of Lamports algorithm and Ricart and
Agarwalas algorithm
Message passing system
74Controller Area Networks
Centralized solution
Controller Area Network
75Controller Area Networks
Decentralized solution
Controller Area Network
76Component-based Programming
77Boeing Bold Stroke Platform
Periodic Aperiodic
Constrained Tactical Links
Many Computers
Mission Computer
Multiple Safety Criticalities
Radar
Vehicle Mgmt
COTS
Information Security
Multiple Buses
O(106) Lines of Code
Hard Soft Real-Time
78Control-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 method
4. Airframe updates its position data and
publishes DATA_AVAILABLE event
5. NavDisplay component fetches AirFrame data by
calling AirFrame GetData method
6. NavDisplay updates the physical display
79System Architecture
ORB
80Event Service
Controller
Sensor1
Actuator1
Sensor2
Actuator2
Sensor3
Actuator3
- One-way communication
Event Service
- Anonymous communication
81Existing Development Methodology
Bold Stroke Components
XML Configuration Specification
82Cadena
Cadena
CCM Interface Definition Language
RT Aspect Specs
State Transitions
System Configuration
High-level Specification Language
Eclipse Plug-In
Integrated Development Environment
83ModalSP
84Three Synchronized Views
Scenario Description
85Textual View
86Graphical View
87Spreadsheet View
ports for component type
port types
port connections
88Aspect Synthesis
Dependency-driven rate assignment to event
handlers
5Hz
20Hz
20Hz
5Hz
20Hz
20Hz
20Hz
89Aspect Synthesis
Asynchronous message delivery to synchronous
method calls (must be co-located and run at same
rate)
Automatic detection of optimization opportunities
5Hz
5Hz
20Hz
20Hz
20Hz
20Hz
1Hz
20Hz
20Hz
90Specifying Synchronization
gps
radar1
navDisplay
airframe
hud
20hz
track1
track2
track3
tacticalDisplay1
track4
track5
tacticalSteering
track6
Mode 1 read from track1,2,4 Mode 2 read from
track 1,,10
tacticalDisplay2
track7
track8
track9
track10
radar
91Specifying Synchronization
Event-driven system Components react to events
- 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 lt e2.notified lt e1.notified 1
- regulates the flow of notifications of e1
and e2 to a - component so that these notifications
alternate
92Taos Real Time Event Channel
Consumer Proxies
Dispatching module
Event correlation
Subscription and filtering
Supplier Proxies
Supplier
- Filtering and correlation is
- on per-consumer basis
93Event Distribution and Coordination Service
Consumer Proxies
Dispatching module
Event correlation
Subscription and filtering
Supplier Proxies
94New Filtering mechanisms
Consumer Proxies
Dispatching module
Event correlation
Synch Module
Subscription and filtering
Supplier Proxies
Supplier
95Condition Event
Consumer Proxies
Dispatching module
Event correlation
Synch Module
Subscription and filtering
Supplier Proxies
Supplier
96Synch Code generation
Scenario Specification
BMDevice MonolithicImpl
BMDeviceCCM (context)
BMDevice MonolithicWrapper
CCMObjectImpl
HomeCCM
Event Service
97Existing Development Methodology
Bold Stroke Components
XML Configuration Specification
98Development Methodology
Bold Stroke Components
Configurator
Synch Module
XML Configuration Specification
Configured Build
- Different synchronization specifications result
in different - Synch_Module
99Related Work
- Top down approach vs Bottom-up approach
- Complimentary approaches
100Bottom-up Approach
- Cool
- Synchronizers
- Composition filters
- Superimposition
101Cool Coordination Aspect Language
- Based on AspectJ C. Lopes and G. Kiczales 1997
- - Coordinator coordinates one or more classes
selfexclusive
mutexclusive
condition variables
102Bounded Buffer in Java
class BoundedBuffer Object array int
putPtr 0, takePtr 0 int usedSlots 0
BoundedBuffer(int capacity) array new
Objectcapacity
103Functional code
BoundedBuffer public void push (Object o)
arrayputPtr o putPtr (putPtr1)array.len
gth usedSlots public Object pop()
Object old arraytakePtr arraytakePtr
null takePtr (takePtr1)array.length
usedSlots-- return old
104Tangling
synchronized void push(Object o) while
(usedSlots array.length) try wait()
catch (InterruptedException e)
arrayputPtr o putPtr (putPtr 1 )
array.length if (usedSlots0) notifyall()
usedSlots if (usedSlots0) notifyall()
105Coordinator
coordinator BoundedStackCoord BoundedStack
selfexclusive pop, push mutexlcusive pop,
push cond boolean full false, empty true
push requires !full on exit if
(sp Max) fulltrue) if (sp 1) empty
false pop requires !empty on exit
if (sp 0) empty true if (sp
Max 1) full false
106Implementation Model
Coordinator
Object
107Synchronizers
- 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
108Synchronizers constraining messages to objects
- message patterns
- constraints
109Synchronizer for allocation policy for two
objects adm1 and adm2
AllocationPolicy(adm1, adm2, max) init
prev 0 prevgt 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,
110Vending machine synchronizer
VendingMachine(accepter,applies,bananas,
apple_price,banana_price) init amount 0
amount lt apple_price disables apples.open,
amount lt banana_price disables banana.open,
accepter.insert(v) updates amount amount
v, (accepter.refund or apples.open or
bananas.open) updates amount 0
111Composition Filters AT98
class SyncStack interface
inputfilters sync Wait
Nonemptygtpop, Truegt\pop
specifies synchronization constraints
- Filters are used to block, buffer and reorder
methods
112Superimposition
- L. Bouge 88Chandy 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
113Basic computation protocol Bguard1 ?
a1lt Bcompute1gt Bguard2 ? a2lt
Bcompute2gt Bguard3 ?
a3ltBcompute3gt
Merged protocol Bguard1 /\ Cguard1 ?
a1ltBcompute1 Ccompute1 gt
Bguard2 ? a2ltBcompute2gt
Bguard3 /\ Cguard3 ?
a3ltBcompute3 Ccompute3gt
Control protocol Cguard1 ? a1lt
Ccompute1gt Cguard3 ? a3lt
Ccompute3gt
114Protocol Composition
115(No Transcript)
116Conclusion
- Aspect oriented approach to synchronization
- SyncGen
- Complimentary to bottom-up approach
- Several back-end translations