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 #F C-3044 and NSF CRCD #EIA

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

2. Mechanically derive a coarse-grained solution from the invariant Coarse grained solution links GI to the program in high- level synchronization construct <await TRUE e.g., nr must be incremented when a thread starts reading and decremented when a thread completes reading. < await> reading

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

< await while not B i do C i.wait( ); Si;Si; SjSj Add C k.signal( ) or C k.signalAll( ) if execution of S i can potentially change the value of B k 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 wait wakeup wait wakeup with synchronization aspect code development Identifying synchronization regions and clusters

Our development methodology Fine-grained code Component code Actors 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 R enter( ); 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 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 1.private Object o i = new Object( ); 2.pubic void method i ( ) { synchronized (o i ) { while (! checkB i ( )) try {o i.wait( ); } catch (InterruptedException e) { } } 3.private synchronized Boolean checkB i ( ) { if (B i ) { S i ; return true; } else return false; }

3.For 1.public void method j ( ) { synchronized (this) { S j ; } } 4.If execution of S i (or S j ) potentially change some B k to ture, add 1.synchronized (o k ) {o k.notify( );}, or 2.synchronized (o k ) {o k.notifyAll( ); } Correctness: 1.B i ; S i ; and S j are all executed in synchronized (this) blocks 2.Nesting level of synchronized blocks is at most two; the order is always block on o k being outside and block on this inside. 3.o i.wait( ); is executed within a sole synchronized block on o i 4.Checking B i and execution of o i.wait( ) are protected inside synchronized block on o i 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) { } GenericJob getJob( ) { } 3.Job threads execute the following code whlie(true){(threadPool.getJob( )).execute( );} jobQueue blocked threads at

Translation Algorithm 1.Declare one monitor for each cluster. 2.For each, declare queue i (queue of GenericJob) declare gMethod i boolean gMethod i (GenericJob job) { if (not Bi) {queue i.enqueue(job); return false; } S i ; return true; } 3.For each, declare ngMethod j void ngMethod j ( ) { S j ; } 4.Add singal k () after S i wherever necessary void signal k ( ) { while ((not queue k.isEmpty( )) ∧ B i ) { S i ; threadPool.addJob(queue i.dequeue( )); }

Job objects 1.Inherit (or implement) GenericJob and override execute( ) 2.Devide the scenario into phases by each appearance of statement 3.Body of execute( ) is switch (phase) { case 0: sequential code derived for phase 0 section of the scenario if (not synchObject.gMethod 1 (this))_{phase = 1; return;} case 1: …. }

Performance Evaluation (Jacobi Iteration 1000x1000) Linux running on MHz Xeon processors

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

 Bound(R, n): at most n threads can be in R Region R In R Out R

 K_MuTex(R 1, R 2, …, R n, k): at most k threads can be in (any) regions R1R1 R2R2 RnRn …

Exclusion(R 1, R 2, …, R n ): threads can be in at most one region out of n regions R1R1 R2R2 RnRn … e.g., Comb(3,2) = {(1,2), (1,3), (2,3)}

Resource((R P, N P ), (R C, N C ), n): Initially, there are n resource items in the resource pool. When a thread executes R P, it produces N P resource items. When a thread executes R C, it consumes N C items. If there are less than N C items in the pool, a thread trying to enter R C waits until there are at least N C items in the pool R C, N C R P, N P n

… R 1, N 1 R 2, N 2 R n, N n Barrier((R 1,N 1 ), (R 2,N 2 ), …, (R n,N n )): all N i threads in R i (1  i  n) meet, form a group, and leave the respective regions together e.g.,

AsymBarrier: Asymmetric version of Barrier, where entries of threads to a set of regions trigger departures of threads from a set of regions R 1, 2R 2, 3 e.g.,

Composition of patterns 1. Composition of invariants Producers/Consumers with n-bounded buffer Readers/Writers problem Bound(R w, 1) ∧ Exclusion(R w, R R ) Resource((R P,1),(R C,1),0) ∧ Resource((R C,1),(R P,1),n) ∧ Bound(R P,1) ∧ Bound(R C,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(R I,1) ∧ Bound(R D,1) ∧ Exclusion(R D, R S ) ∧ Exclusion(R D, R I )

2. Composition of sub-clusters Readers/Writers problem Exclusion R RWRW Bound R RWRW Exclusion (1)(2)

Information Exchanging Barrier ((R 1, N 1 ), (R 2, N 2 ), …(R N, N N ) Bound (R 1, N 1 )Bound (R 2, N 2 )Bound (R N, N N ) (R 1, N 1 ) (R 2, N 2 ) (R N, N N ) write read ….. 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((R C1, 1), (R P1, C)) Steps [C3] and [P2]: AsymBarrier([(R C3,1)],[(R P2,C)]) Steps [C4] and [P3]: AsymBarrier([(R P3,C)], [(R C4,1)])

C3 C2P4 Coaster Thread Passenger Thread P2 P3C4 C1P1 R C1 1 R C3 1 R C4 1 R P1 C R P2 C R P3 C Barrier 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 R C4 1 C1 R C1 1 R P1 C R P3 C C3 R C3 1 R P2 C Info Exchanging Barrier Specific AsymBarrier R c2 Bound Specific AsymBarrier

C2 P4 Coaster Thread Passenger Thread P2 P3C4 P1 R C4 1 C1 R C1 1 R P1 C R P3 C C3 R C3 1 R P2 C Info Exchanging Barrier Specific AsymBarrier R c2 Bound 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 parentbaby B2 B3 B4 B5 B6 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 Cluster [P3, C1]: AsymBarrier

Write Read …. Consumer nConsumer 2Consumer 1Producer

Evaluation 1 (most difficult) (easiest) Ave. Ad-hoc GI no patterns GI with patterns 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. Q uestionnaire

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 Synchronization Aspect Specification Tool Intermediate Representation Generator Solver/ Prover Course-grain solution Synchronization Aspect Back-end Bandera Analysis & Transformation Fine-grain solution Specialization Engine Bandera Safety Properties Liveness Properties Code Weaver Optimized Woven Code Invariant & Region tags Functional Core Code Templates (Java, C++, …) Template Instantiation Traditional Development Environment Functional Core Code (Java, C++, …) Finite State Models

Verification Wait until gyroscope value is in buffer Read value from buffer Actuate rudder based on value Read a value from the gyroscope Wait 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(R G,R R,0) + Resource(R R,R G,1) + Exclusion(R G,R R ) Synchronization Specification … built on top of Bandera System Model Core Code Model Sync Code Model Bandera

Verification Wait until gyroscope value is in buffer Read value from buffer Actuate rudder based on value Read a value from the gyroscope Wait 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(R G,R R,0) + Resource(R R,R G,1) + Exclusion(R G,R R ) Synchronization Specification System Model Bandera Core Code Model Sync Spec Model Derived from specification Derived from specification RW State space: Full Java: 1,559,250 Hybrid: 534

C w/ CAN Message Passing C w/ CAN Message Passing C++ Posix Threads Generating Fine-Grain Solution C1++> C2++> C3++> C4++> Cn++> Java C++ w/ CORBA Event Channel C++ w/ CORBA Event Channel Back end Translators

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 P 1,…,P n : processes/components R 1,…,R m : regions St 1,…,St n : await statements St x : Message passing system

Asynchronous message passing systems Message passing system Extensions of Lamport’s algorithm 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 WeaponsNav Sensors Weapon Management Data Links Many Computers Multiple Buses Constrained Tactical Links O(10 6 ) Lines of Code Hard & Soft Real-Time Periodic & Aperiodic Multiple Safety Criticalities Information Security Focus Domain Mission Computer Vehicle Mgmt COTS

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 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

System Architecture ORB Event Service Event propagation Data Service Data propagation

Event Service Sensor1 Sensor2 Sensor3 Actuator2 Actuator1 Controller Actuator3 - One-way communication - Anonymous communication Event Service

Existing Development Methodology … Bold Stroke Components XML Configuration Specification 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 QoS Aspect Synthesis XML Configurator Info Cadena Integrated Development Environment High-level Specification Language CCM Interface Definition Language RT Aspect Specs State Transitions System Configuration Eclipse Plug-In

ModalSP

Three Synchronized Views Scenario Description Scenario Description Single Internal Representation Spreadsheet View Spreadsheet View Graphical View Graphical View Textual View Textual View

Textual View

Graphical View

Spreadsheet View …ports for component type …port types …port connections …distribution sites …rate group RT Attributes

Aspect Synthesis Dependency-driven rate assignment to event handlers 5Hz 20Hz 1Hz 20Hz

Aspect Synthesis Automatic detection of optimization opportunities 5Hz 20Hz 1Hz 20Hz Asynchronous message delivery to synchronous method calls (must be co- located and run at same rate)

tacticalDisplay1 tacticalDisplay2 hud navDisplay airframe tacticalSteering radar tracksensor1 tracksensor2 tracksensor3 tracksensor4 track1 track2 track3 track4 track5 track6 track7 track8 track9 track10 radar1 gps coherent Both must be on at the same time Mode 1: read from track1,2,4 Mode 2: read from track 1,…,10 dynamic correlation atomic 20hz 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 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 Synch Module - 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 Synch Module Update state Synch_event are redirected to the Synch_Module Notifications for Synch_notify events are redirected to the Synch_Module 0/1

Supplier Proxies Dispatching module Consumer Proxies Event correlation Subscription and filtering Condition Event Supplier Consumer Synch Module Update state Condition events

Synch Code generation Event Service Scenario Specification BMDevice MonolithicImpl BMDeviceCCM ( context ) BMDevice MonolithicWrapper CCMObjectImpl HomeCCM Configured Event Service Synch. Specification Synch_Module

Existing Development Methodology … Bold Stroke Components XML Configuration Specification Configured Build Synchronization specifications - component behavior is modified by including control code in the components Configurator

Development Methodology … Bold Stroke Components Configured Build Configurator XML Configuration Specification Synchronization specifications Synch Module -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 code BoundedBuffer { 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; } }

Tangling synchronized 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(); }

Coordinator coordinator 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

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: [] Bguard2  a2: [] Bguard3 /\ Cguard3  a3: : } Control protocol: *[ Cguard1  a1: [] Cguard3  a3: [] : ] Basic computation protocol: *[ Bguard1  a1: [] Bguard2  a2: [] Bguard3  a3: : ]

Bi-directional data transfer Flow control Token-passing Protocol Composition

Conclusion  Aspect oriented approach to synchronization  SyncGen  Complimentary to bottom-up approach  Several back-end translations