Composing Multiple-Client-Multiple-Server Synchronizations

Mehmet Aksit and Lodewijk BergmansTRESE project, CTIT and Department of Computer Science,

University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands.email: {aksit, bergmans}@cs.utwente.nl

http://wwwtrese.cs.utwente.nl

Abstract

A considerable number of language mechanisms havebeen proposed during the last several years, to specifyand implement concurrent object-oriented programs. Themajor concern of these proposals is to design anexpressive language that provides extensible concurrentprocessing and synchronization features. Almost all theseefforts, however, have focused on the multiple-client-single-server model where each server determines itssynchronization semantics without cooperating with otherobjects. We believe that object-oriented concurrentlanguages must not only support a single-server model,but cooperatively synchronizing servers as well. We referto this as multi-server synchronization. This paper firstclassifies multi-server synchronization in five categories.The intention here is to define a framework for evaluatingcurrent approaches and identifying the requirements fordesigning new languages. In addition, this paper presentsa composable multi-server synchronization technique,adopting the concept of composition-filters.

1. Introduction

It has been claimed that object-oriented languageconstructs are very suitable for expressing concurrencyand synchronization since more than one object can beactive concurrently [36]. In addition, inheritance can helpin reusing well-designed and verified concurrentprograms. This may reduce the efforts in writingconcurrent applications, as concurrent systems are harderto design and implement. During the last several years, aconsiderable number of object-oriented languages havebeen introduced as a tool to develop concurrent object-oriented programs [7, 24, 11, 16, 30, 27]. Theselanguages aim at constructing expressive and extensibleconcurrent programs. Since most early concurrent object-oriented languages failed in combining their concurrency

and synchronization mechanisms with the inheritancestructure, a major portion of the recent research activitieswere devoted to solve the so-called synchronizationinheritance anomalies [29].

Almost all of the research activities in concurrentobject programming have been focused on the multiple-client-single-server model, where synchronizationsemantics are determined by the server object only. Alarge number of applications, however, requirecooperatively synchronizing server objects.

Although there have been some efforts to modelcoordinated behavior among objects explicitly [22, 5],these activities were mainly targeted on functionalityrather then the reuse of synchronization semantics ofcoordination.

In this paper we present five types of synchronizationsthat one may need in expressing multi-serversynchronization schemes. Our intention here is to presenta framework for evaluating current approaches andidentify the requirements of the future object-orientedlanguages.

To solve multi-server synchronization problems, weapply the concept of composition-filters. Composition-filters are modular and orthogonal extensions to theconventional object model. Filters can be used, forexample, to express synchronization per object basis.Filters can also express meta-level architectures. Throughthe orthogonal composition of meta-level architecturesand synchronization filters, one may implement themulti-server synchronizations in a composable way.

The following section introduces an abstract objectmodel which is used to identify the issues in definingmulti-server synchronizations. Section 3 defines the fivetypes of multi-server synchronizations that one may needin constructing concurrent object-oriented programs.Based on this classification, section 4 evaluates thebackground and related work. Section 5 applies thecomposition-filters concept as a possible solution toexpress composable multi-server synchronizations.

1

Finally, evaluation of the proposed approach andconclusions are presented in section 6.

2. Definitions

The concept of encapsulating a shared resource as aserver module which reacts to request messages from itsclients forms the basis of object-based concurrentprogramming [36]. In the multiple-client-single-servermodel, the policies for the synchronization of concurrentoperations invoked on the shared server object aredetermined by the server object only. Most object-orientedconcurrent languages provide this kind ofsynchronization.

A bounded buffer object accessed by several clientobjects is a typical example of the multiple-client-single-server model. A bounded buffer object provides theoperations get and put, which remove and add elementsfrom and to the buffer, respectively. In addition to mutualexclusion, there are two boundary situations that requiresynchronization. In the first case if the buffer stores noelements at all, a get operation must be blocked until newelements are added. In the second case, if the buffer isfilled to its limit, then no more put operations must beaccepted until additional space is available.

Object-oriented concurrent programming extends theobject-based model by adding inheritance-likemechanisms [24, 8, 13, 15, 26, 31, 30, 9, 10]. Mostconcurrent object-oriented languages, in one way oranother, fail in combining their concurrency andsynchronization mechanisms with the inheritancestructure. This failure is referred to as inheritanceanomaly [29]. Ideally, development methods and languageconstructs should be able to express concurrency andsynchronization while maintaining a high degree ofmodularity, extensibility and reusability.

By distributing the synchronization functions of thesingle-server object, the multiple-client-multiple-server(in short multi-server) model can be realized. To identifythe related issues of multi-server synchronizations andevaluate the existing approaches, a model is presented infigure 1. For simplicity, we do not make distinctionbetween objects and classes. The model is characterizedby five basic relations. The first two relations areinheritance and delegation. As shown by the figure, thesynchronization specification of the server object can becomposed from other objects through inheritance and/or

delegation relations1. Inherited and/or delegated objectscan be seen as extensions of the server object. Thirdly, an

1 We mean the composition of an object’s signature (or visiblebehavior) from the signatures of one or more objects.

object may exchange messages with its peer objects toimplement a distributed synchronization. Fourth, asynchronization specification can be associated with oneor more objects. Finally, some constraints can be definedon these relations. Here we restrict ourselves to orderingconstraints. Ordering of message sends is supported bythe conventional object model in the implementation ofobject’s operations. Ordering of a synchronizationspecification is again a synchronization specification.Therefore, we only consider here ordering ofcompositions.

Figure 1. The reference object model for theanalysis of multi-server synchronization issues.

3. Categories of synchronizationcompositions for multiple-servers

This section discusses the five basic relations asidentified in the multi-server synchronization referenceobject model.

3.1. Synchronization composition throughinheritance

In the first case, the synchronization of the serverobject is composed through the inheritance mechanism.The abstract object model as shown in figure 2(a)illustrates this approach. Inheritance of synchronizationspecifications has been studied extensively in the

literature [29, 9, 10]2.Consider class LockingBuffer that inherits from both

class BoundedBuffer and class Locking. ClassLockingBuffer is a bounded buffer that can be locked andunlocked. If the buffer is locked no methods are accepted

2 Composition of synchronization using inheritance only corresponds tomultiple-client-single-server model. Since the single-server model canbe seen as a special case of the multiple-server model, and for thesake of completeness we discuss synchronization inheritance here.

2

for execution, except the method unlock that removes thisrestriction. This example is illustrated by figure 2(b). Thestates of objects are shown as circles within objects. Theremay be two problems experienced in the realization ofLockingBuffer. Firstly, the synchronization constraints thatare defined by the two classes are sometimescontradictory. For example, suppose an instance ofLockingBuffer is in the locked state and contains a fewelements. Class Locking dictates that no method exceptunlock is to be accepted. According to classBoundedBuffer, however, the methods put and get shouldbe acceptable. These conflicting constraints must beresolved. The second problem is that the synchronizationconstraints defined by Locking are to be applied on themethods of a subclass. These methods are not known yetwhen Locking is defined. It is thus important to define aform of open-endedness in the synchronizationspecification.

Figure 2. (a) An abstract model of LockingBuffer.Here n = 2. (b) Composition of the synchronization ofLockingBuffer from classes Locking and BoundedBuffer.

3.2. Synchronization composition throughdelegation

The delegation mechanism allows objects to sharebehavior at the object level [25]. Figure 3(a) shows anabstract object model of synchronization compositionsusing both inheritance and delegation. For example, infigure 3(b), object SharedLockingBuffer inherits fromBoundedBuffer and delegates to the shared objectSharedLocker of class Locking. If a lock or an unlockmessage is invoked on one of the SharedLockingBuffer

objects, then this request will be delegated to theSharedLocker object. Since delegation is defined at theobject level, the state of the locker can be shared bymultiple buffers. This makes it possible to distribute thelocking synchronization among multiple buffer objects.

The problems that may be experienced here aresimilar to the previous example. In addition, since thedelegated object is global, the delegation operation ofbuffer objects may interfere with each other. Therefore,mechanisms must be introduced to synchronizeconcurrent delegations.

Figure 3. (a) The abstract model ofSharedLockingBuffer. (b) Schematic representation.Here, locking synchronization is shared by multiplebuffers through delegations.

3

3.3. Cooperating synchronizations

Consider the definition of class DistributedBuffer, asshown by figure 4. The interface of DistributedBuffer is thesame as the one of BoundedBuffer. If a distributed bufferobject receives a get message and the buffer is empty, thenit interacts with other buffer objects to retrieve an item forits client object. The message is only queued if all thecooperating buffers are empty. Similarly, if the buffer isfull and a put message is received, then the buffer objecttries to find a free buffer to store the item. If all the bufferobjects are full, then the put message is queued.

Figure 4. (a) Interaction diagram and (b) compositionhierarchy for coordinating buffers.

The abstract object model of DistributedBuffer is shownin figure 5. As depicted in the figure, each object has itsown synchronization specification. However, objectsexchange messages to implement a distributedsynchronization.

There are two important aspects in realizingcoordinating synchronizations among distributed servers.Firstly, coordinating servers must be compatible. Anessential requirement is that servers must be functionallycompatible. If functional compatibility does not exist,cooperation is not possible. If, however, proceduralcompatibility does not exist, but the components arefunctionally compatible, cooperation can only be obtainedby introducing a suitable adaptation module which

translates between the communication patterns used bythe different servers. The second requirement is thesynchronization of distributed servers (synchronization ofdistributed synchronizations). The cooperation can berealized in a distributed way, or in a centralized mannerby using explicit coordination objects.

Figure 5. An abstract object model for cooperatingsynchronizations.

In the example, since the cooperating buffers arefunctionally compatible, it should be possible toimplement class DistributedBuffer based on cooperatingmultiple bounded buffers.

3.4. Polymorphic synchronization compositions

Polymorphic synchronization composition allows thesame synchronization specification to be used in differentkinds of cooperation. Consider, for example, atomictransactions. Transactions attempt to maintain systemconsistency by dealing with possible problems due toexceptions, system failure, and multiple concurrentactivities, and in most systems guarantee the permanenceof the updates made during a transaction as well. One ofthe important characteristics of transactions is theserialization of executions [20], which requiressynchronization of objects that participate into atransaction.

Figure 6 shows cooperating locking objects. If themethod lock is invoked on one of the cooperating lockers,then after locking itself, this object locks all the otherlockers. Similarly, the unlock operation unlocks all thelockers. The cooperation among lockers may result ininconsistencies if the distributed locking or unlockingprotocols are not atomic. For example, before all theobjects are locked, some other object can refer to thestatus of one of the lockers or may even try to unlock it.To avoid inconsistencies, an atomic transaction objectcan be composed with the cooperating lockers.

4

Figure 6. Polymorphic composition of the atomicobject with the coordinating locking objects: (a)interaction (b) composition diagram.

Figure 7. Polymorphic association of synchronizationspecification.

Atomic transactions are not only needed forcooperation among lockers but can be useful in otherapplications as well. For example, cooperating buffersshown in figure 4 could also adopt a transactionalmechanism. The atomic transaction object has its ownsynchronization properties. This results in polymorphicapplications of synchronization semantics of atomictransactions in different cooperation patterns. Otherexamples of polymorphic synhronizations areasynchronous message sending and broadcasts.

Figure 7 shows an abstract model for polymorphicsynchronizations, where the same synchronizationspecification is associated with multiple objects. In theatomic transaction model, serialization is enforced onmessage executions as a synchronization constraint.

3.5. Ordered compositions

It may be desirable sometimes to order thecompositions of objects. This is shown in figure 8through the definition of class ProtectedLockingBuffer.Class ProtectedLockingBuffer delegates to object Verifierof class Login and inherits from classes Locking andBoundedBuffer.

Figure 8. (a) Abstract model for orderedcompositions. (b) Ordered composition ofProtectedLockingBuffer: first the methods of Login,then Locking and BoundedBuffer are allowed.

The class Login has two methods verify and change.The method verify accepts name and password as anargument and controls whether this pair is registered inthe local access-list. If not, an error condition is raised.The method change is used to add or remove names andpasswords to or from the access-list. Assume that theoperations of class ProtectedLockingBuffer have to beinvoked according to its composition structure; first anymethod of Login, then Locking and BoundedBuffer mustbe invoked. Not following this order creates an errorcondition or the request is queued until it is acceptable.

The conventional object-oriented model does notprovide any facility to order inheritance and/or

5

composition hierarchies as illustrated by figure 8. Onepossibility is to declare each composition possibility as aseparate method in the subclass, and invoke the inheritedor delegated methods through super calls. In our example,this would require eight method definitions. It may beclear that the number of possible method combinationscan be quite large, and it would not be feasible to declareall possible combinations separately.

4. Background and related work

This section analyzes the state-of-the-art objecttechnology in implementing multiple-serversynchronizations.

4.1. Multiple-client-single-server models

As we stated before, most research in the area ofconcurrent object-oriented programming has focused onsingle server synchronization. Here we considermechanisms where synchronization is performed byblocking the received messages at the boundary of objects,before the corresponding method is executed.

Several types of message passing semantics have beenadopted by concurrent object-oriented languages.Examples are asynchronous message passing, where anobject continues execution after sending a request, withoutwaiting for a reply (supported e.g. in ABCL [36], Eiffel//[13] and Parallel Objects [14]) and the common blockingremote procedure call, where the sender of the messageblocks until it receives a reply .

In addition, several types of synchronization schemeshave been proposed. Two distinct approaches arerespectively explicit acceptance and activation conditions.Explicit acceptance means that during of a methodexecution, the state of the object is considered, and basedon this it is explicitly decided what message to acceptnext. For example ABCL/1 [36], POOL [7] and Eiffel//[13] support this approach.

Activation conditions define for each message whetherit should be accepted or blocked. In some languages theactivation conditions can be manipulated directly (e.g.Actor languages [1] and Hybrid [33]). In other languagesand systems the activation conditions are specifiedindirectly, e.g. through guards (e.g. in [16], Guide [15]and Concurrency Annotations [26]), path expressions (e.g.PROCOL [11]) or state abstractions (e.g. ACT++ [24],Rosette [34] and Synchronizing Actions [32]). Theproposal in [30] combines activation conditions through(polymorphic) guards with state abstractions.

4.2. Using distributed protocols within code

If the adopted programming language does notprovide any appropriate language construct to definemulti-server synchronization, the programmer is forcedto implement synchronization, in case such asynchronization scheme is necessary. For example, classDistributedBuffer can be defined by modifying theimplementations of the methods put and get, which areinherited from class BoundedBuffer. When the buffer isfull and a put message is received, the buffer object maycoordinate with other objects to find out a suitable bufferobject to store the item. Similarly, if the buffer is emptyand a get message is received, then the get method can beextended with a piece of code to retrieve a suitable itemfrom other buffers. This way of implementing multi-server synchronization mixes the synchronization codewith the application code. As a consequence, changingthe distributed synchronization scheme in the subclass orchanging the behavior of the method may require theredefinition of both the synchronization specification andthe behavior, although this may not be necessary.

4.3. Using language keywords

A programming language may provide a set ofkeywords for distributed synchronization. For example,language constructs such as begin_transaction andcommit_transaction can be used to designate a transactionblock. Another example is coordinated termination,where the sender object sends multiple messages andthen waits until it receives e.g. a single reply, or allreplies (as provided in ABCL/1 [36] and Orient 84K[23]).

One of the disadvantages of these approaches is thatsuch language constructs have to be specified within thebody of the method. This results in mixture ofsynchronization specification with the application code.This may cause inheritance anomalies. Secondly, byusing dedicated language keywords, only a fixed set ofsynchronization constraints can be specified.

4.4. Using languages with explicit inter-objectcommunication modules

Several language mechanisms have been proposed inthe past for modeling coordinated behavior amongobjects. These language designers claimed thatcoordination among objects must be represented as first-class objects. For example, a language construct calledscripts [18] was introduced to abstract patterns ofmessages into a module. A script is a parameterizedprogram section in which processes enroll in order to

6

participate. The concept of enrollment is similar to thesubroutine call mechanism whereby the execution of therole in a given script instance is a logical continuation ofthe enrolling process. A script consists of formal processparameters called roles, data parameters and a concurrentprogram section called the body. Processes can enroll inscripts by means of enroll in statements.

In the object-oriented modeling area, contracts [21, 22]were defined to specify the contractual obligations that aset of participants must satisfy. A contract specificationincludes the specification of the participating objects, thecontractual obligations of all participants, the invariants tobe maintained by the participants and the method whichinstantiates a contract.

In [5], Abstract Communication Types (ACTs) weredefined to model coordinated behavior among objects as aclass. ACTs can be uniformly integrated with thecoordinating objects using the composition-filters concept.

Both scripts, contracts and Abstract CommunicationTypes basically aim at modeling the functionalcoordinated behavior among objects. Therefore, theselanguage mechanisms fail in expressing composablemulti-server synchronizations.

4.5. Using concurrent reflective languages

Reflective languages can observe and influenceacceptance of message at a meta-level. At the meta-levelthe full expression-power of the language is available, andtherefore virtually any synchronization scheme can beprogrammed. Examples are ABCL/R [35], Actalk [12]and MAUD [17].

Reflective architectures can realise both single-serversynchronizations, through individual-based reflection, ormultiple-server synchronizations, through group-widereflection, or a combination of these, through a hybridarchitecture [28]. Similar to the languages that provideexplicit modules for coordinated behavior, the basicmotivation of these languages is to provide open languagestructures to implement, for example, coordinatedbehavior among objects. These languages, however, donot aim at providing abstraction mechanisms to expresscomposable multi-server synchronizations.

5. Addressing multi-server synchronizationcomposition problems

5.1. Synchronization in the composition-filtersmodel

In this section, first we will present an object-orientedmodel to express synchronization compositions. This

model is based on the composition-filters concept.Secondly, we will apply this model to solve the multi-server synchronization problems which were presented inthe previous section.

The composition-filters model is a modular extensionof the conventional object model. Each message thatarrives at an object is subject to evaluation andmanipulation by the filters of the object. In figure 9, themanipulation of messages by the filters of an object isdepicted. One of the things that filters can do, as will beexplained in more detail next, is to block a message andput it in the message queue until a certain constraint issatisfied. Filters are modular extensions to theconventional object model because the conventionalobject model can be viewed as an object with a

transparent filter3.

Figure 9. The manipulation and buffering ofmessages at the filters of an object.

Figure 10 shows the interface definition of classBoundedBuffer, expressed in the Sina syntax. Sina is anexperimental language that adopts the compositional-filters model. The composition-filters model, however, isgeneral and can be applied to other object-oriented

languages as well4.In lines 6 and 7, two methods put and get are

declared. The major extensions to the conventional objectmodel are condition and filter declarations, ashighlighted by gray boxes. Lines 3 and 4 of the class

3 The composition-filters approach is a modeling paradigm rather thanthe definition of a particular language with fixed semantics. Thesemantics of objects expressed in the composition-filters model can belargely determined by the semantics of the filters. Similar toextensions of a photo camera, the design of each filter can deal with adifferent problem and may adopt a different technique For example,designing a color filter may require different skils than designing aninfra-red viewer. Several different filter types have been defined in thepast. For example, [2] illustrated how both inheritance and delegationcan be simulated using filters. In [3] filters were introduced fordefining reusable transactions. Language-database problems wereaddressed in [4]. In [5], filters were used to abstract coordinatedbehavior among objects. The application of composition-filters forcomposing synchronization and real-time specifications waspublished in [6, 10].

4 Currently, we are developing filter extensions for Smalltalk and Javaobjects.

7

definition declare the conditions Empty, Partial and Full,which correspond to the three states a bounded buffer canbe in. The second extension is the declaration of two

filters in lines 9 and 10 following the inputfilters5 clause.A filter determines whether a particular message isaccepted or rejected. It also determines what action is tobe performed in either case. Each filter is declared as aninstance of a filter class. A programmer may define anarbitrary number of filters in a class declaration. In theBoundedBuffer example of figure 10, lines 9 and 10declare two filters, respectively instances of class Wait and

class Dispatch6.

class�%RXQGHG%XIIHU�interfacecomment�LPSOHPHQWV�D�ERXQGHG�EXIIHU�ZLWK

������������V\QFKURQL]DWLRQ�conditions

(PSW\��3DUWLDO��)XOO�methods

SXW�$Q\��returns�1LO�JHW�returns�$Q\�

inputfiltersEXIIHU6\QF���:DLW� �^�(PSW\ !SXW�

����������������3DUWLDO !^SXW��JHW`��)XOO !JHW�`�H[HFXWH���'LVSDWFK� �^�LQQHU� �`�

end ���class BoundedBuffer interface

Figure 10. Interface declaration of classBoundedBuffer.

A filter of class Wait has the following intuitivedefinition. When a message arrives at a Wait filter, it canonly proceed when the message is accepted by the filter,and it will be blocked otherwise, until the message can beaccepted by the filter. In line 9, an input filter calledbufferSync of class Wait is declared as:

bufferSync : Wait = { Empty=>put,Partial=>{put, get}, Full=>get };This filter specification corresponds to a mapping from

the conditions Empty, Partial and Full to the messages putand get. The ‘=>‘ symbol accepts the messages on itsright hand side when -one of- the conditions on the lefthand side is satisfied. This mapping results in a guard-based specification, where a guard that is composed of

5 In addition to input filters, the composition-filters model also supportsoutput filters. Output filters affect outgoing messages, whereasinputfilters affect incoming messages. For brevity, we do not furtherconsider output filters in this paper.

6 The current version of the Sina language provides a number ofprimitive filters types, such as Dispatch, Meta, Error, RealTime andWait. The Dispatch, Wait, Meta and Atomic filters are used andexplained in this paper. The Error filter is similar to the Dispatchfilter but it does not provide a method dispatch; it raises an errorcondition if a message does not pass through the filter [4]. TheRealTime filter is used to impose real-time constraints on messages[6]. All filter types can be used for both input and output filters. Animportant feature of all these filters is that their functionality isorthogonal and therefore they can be combined freely.

one or more conditions is defined for each message.When new methods are added to the class or one of itssubclasses, additional messages can be associated withthe conditions, or new conditions can be associated withmessages.

The Dispatch filter defines a simple matchingmechanism that maps all received messages to the local(‘ inner’) methods. The wild card ‘*’ implies that allmessage selectors -that are supported by the object- areacceptable. The Dispatch filter takes care that a messagethat does match will be dispatched. Dispatching to a localmethod results in execution of that method.

5.2. Using filters for synchronization inheritance

To demonstrate applicability of the filter concept tothe composition of synchronization through inheritance,an additional class with synchronization behavior isintroduced. This is class Locking, which implements themechanisms for locking an object so that all messages itreceives except the unlock message are blocked. If theobject is unlocked and another unlock message isreceived, this will be blocked until the object is lockedagain.

��� class�/RFNLQJ�interface��� comment DQ�DEVWUDFW�FODVV�WKDW�FDQ�EH�SXW������LQWR�D�ORFNLQJ�VWDWH�DQG�XQORFNHG�DJDLQ���� conditions��� 8QORFNHG��/RFNHG�(5) methods��� ORFN�returns�1LO���� XQORFN�returns�1LO���� inputfilters��� ORFNV\QF���:DLW� �^�/RFNHG !XQORFN������������������������������8QORFNHGa!ORFN�`����� H[HFXWH���'LVSDWFK� �^� �`����� end�

Figure 11. Definition of class Locking.

We omit the implementation of this class thatmaintains the state (free or locked) of the object, as this isstraight forward. In line 4, the conditions Unlocked andLocked are declared. The two methods of the class lockand unlock are declared in lines 6 and 7. As shown inline 9, the synchronization filter locksync consists of twoelements. The first element Locked=>unlock specifiesthat, if the object is in the Locked state only the unlockmessage is accepted. The second element is defined usingthe symbol “~>” instead of “=>”. Unlocked~>lockspecifies that if the object is unlocked, all messagesexcept the lock message are acceptable.

The composition of the locking synchronization withthe bounded buffer synchronization is shown by classLockingBuffer in figure 12:

8

��� class�/RFNLQJ%XIIHU�interface��� internals��� EXIIHU���%RXQGHG%XIIHU���� ORFNHU���/RFNLQJ���� conditions��� EXIIHU� ���ORFNHU� ����PDNH�WKH�FRQGLWLRQV�DYDLODEOH�RQ�WKH�LQWHUIDFH��� inputfilters��� ORFNHU�ORFN6\QF���� EXIIHU�EXIIHU6\QF����� H[HFXWH���'LVSDWFK� �^�EXIIHU� ���������������������������������ORFNHU� �`����� end�

Figure 12. Interface part of class LockingBuffer.

In lines 3 and 4, class LockingBuffer declares twointernal objects buffer and locker which are instances ofclasses BoundedBuffer and Locking, respectively. Thereason for creating these two internal objects is tocompose the behavior and synchronization ofLockingBuffer from the behavior and synchronization ofthese two objects. Class LockingBuffer does not declarenew methods; all its methods are inherited fromBoundedBuffer and Locking classes. In line 6, all theconditions defined by buffer and locker objects are madeavailable to class LockingBuffer using the expressionbuffer.*; locker.*; in the conditions clause. This isrecommended to make sure that future extensions can stillrefer to these conditions. The implementation ofconditions remains encapsulated within the object. Lines 8and 9 define two filter specifications locker.lockSync andbuffer.bufferSync which refer to the wait filters of theinternal locker and buffer objects, respectively. Thesefilters ensures that both synchronization constraints aresatisfied for a message before it can be executed.

The Dispatch filter in line 10 specifies that allmessages that can match the signature of buffer of classBoundedBuffer are dispatched to the buffer object, and allremaining messages that can match the signature of lockerof class Locking are dispatched to the locker object. Amessage that cannot match with either of these will causean exception. As a result of this filter, class LockingBufferoffers a behavior that is a composition of bothBoundedBuffer and Locking. The synchronization forLockingBuffer is a composition of the synchronization ofthese two classes, and the messages of both classes areavailable on the interface of LockingBuffer. Declaringinternal objects and making their methods available at theinterface of the encapsulating object is equivalent to amultiple inheritance mechanism; the classes of these twointernals are then the super classes.

Two important properties of the specification of theDispatch filter are that (a) it puts an ordering on themessages provided by the composed objects, whichresolves possible naming conflicts. The filter specificationcan be tailored to select particular messages from either of

the components. And (b), a dispatch of a message to acomponent differs from a message invocation in that thereceiver of the dispatch message is a part of the extendedidentity of the composed object. The pseudo-variable

server7 will always refer to the original receiver of amessage. In summary, the dispatch filter can simulatemultiple inheritance while resolving potential nameconflicts.

5.3. Using filters for synchronization delegation

The composition of synchronization throughdelegation is very similar to the previous example; themost important difference is that the class defines acomposition using a shared object rather than a privateinstance. This is exemplified by the SharedLockingBufferexample in figure 13.

��� class�6KDUHG/RFNLQJ%XIIHU�interface��� externals��� VKDUHG/RFNHU���/RFNLQJ���� internals��� EXIIHU���%RXQGHG%XIIHU���� conditions��� EXIIHU� ���VKDUHG/RFNHU� ����FRQGLWLRQV�DUH�DYDLODEOH�RQ�WKH�LQWHUIDFH�IRUIXWXUH�FRPSRVLWLRQV��� inputfilters��� VKDUHG/RFNHU�ORFN6\QF� ���GHOHJDWH�V\QFKURQL]DWLRQ�WR�VKDUHG/RFNHU�RI�FODVV�/RFNLQJ���� EXIIHU�EXIIHU6\QF�

���LQKHULW�EXIIHU�V\QFKURQL]DWLRQ�IURP�FODVV������%RXQGHG%XIIHU���� H[HFXWH���'LVSDWFK� �^�EXIIHU� ���������������������������������VKDUHG/RFNHU� �`����� end�

Figure 13. Interface part of classSharedLockingBuffer.

In line 3, class SharedLockingBuffer declares anexternal object sharedLocker, which is an instance ofclass Locking. Object sharedLocker is global and can beshared by multiple objects. In line 5, the class alsodefines an internal object buffer, which is an instance ofBoundedBuffer.

In line 7, all the conditions of both buffer and thelocking objects are made available for theSharedLockingBuffer object through the wild card symbol‘*’.

The execute filter dispatches the messages to bufferprovided that these messages are supported by its classBoundedBuffer. The messages that are supported by thesignature of class Locking are dispatched to the globalobject sharedLocker.

7 Comaparable to self in Smalltalk and this for virtual functions inC++.

9

This example demonstrates a combination ofinheritance and delegation; the behavior and instancevariables of class BoundedBuffer are inherited, and a partof the behavior of SharedLockingBuffer is delegated to aninstance of class Locking. In the case of dispatchingmessages to the sharedLocker object, the server pseudo-variable will still refer to the instance of classSharedLockingBuffer, which resolves the so-called self-problem [25]. Obviously, with an appropriate dispatchfilter a single object can delegate to multiple objects, evenwhile inheriting from one or more classes.

5.4. Composition of cooperatingsynchronizations

To exemplify the composition of cooperatingsynchronizations, we introduce two classes,DistributedBuffer and Distribution. DistributedBuffercooperates with other distributed buffers to achieve its(synchronization) behavior, whereas class Distributiondefines an intermediate object that is responsible fordistribution of messages among the buffer objects.

In this specific example, whenever a distributed buffercannot accept a request, an attempt is made to findanother buffer object to service this request. If this attemptdoes not succeed, the request will be blocked at theoriginal buffer. We will now first describe classDistributedBuffer, and then continue with classDistribution.

Figure 14 shows the definition of DistributedBuffer. Inline 3, class DistributedBuffer declares an external objectbufferDistribution of class Distribution. Line 5 declares aninternal object buffer of class BoundedBuffer. As shown inline 7, all the conditions of the BoundedBuffer object aremade available to DistributedBuffer. The distinguishingfeature of this class is the filter distributeBuffer, aninstance of class Meta filter, which is declared in lines 9and 10. A meta filter is used to convert messages toobjects. This conversion is called reification. If a messageis accepted by a meta filter, the message is reified and sentto the designated target object. If the message is rejected,then it passes to the next filter.

��� class�'LVWULEXWHG%XIIHU�interface��� externals��� EXIIHU'LVWULEXWH��'LVWULEXWLRQ���� internals��� EXIIHU���%RXQGHG%XIIHU���� conditions��� EXIIHU� ����FRQGLWLRQV�RI�%RXQGHG%XIIHU�DOVR�DYDLODEOH�RQWKH�LQWHUIDFH�RI�'LVWULEXWHG%XIIHU��� inputfilters��� GLVWULEXWH%XIIHU���0HWD �����^ )XOO� !�>SXW@�EXIIHU'LVWULEXWH�GLVWULEXWH����� (PSW\� !�>JHW@EXIIHU'LVWULEXWH�GLVWULEXWH�`����� H[HFXWH�'LVSDWFK ^�EXIIHU� �`����� end����� class�'LVWULEXWHG%XIIHU�implementation���� initial���beginEXIIHU'LVWULEXWRU�SXW6LWH�VHOI��end����XSGDWH�EXIIHU'LVWULEXWRU�WR�DGG�P\VHOI���� end�

Figure 14. Interface of class DistributedBuffer.

In line 9, if the condition Full evaluates to true, and therequest is put, then the message is reified and passed asan argument to object bufferDistribute by invoking themethod distribute. This is equivalent to sending themessage:

bufferDistribute.distribute(aMessage)Here, bufferDistribute is the external object and

aMessage is an instance of class Message whichrepresents the reified message. The method distribute willtake care of distributing this request, as will be explainedlater.

In line 10 the second part of the meta filter is defined.If the condition Empty evaluates to true, and the requestis a get message, then this message is reified and passedas an argument to object bufferDistribute by invoking themethod distribute. The messages that are not accepted bythe meta filter are passed to the next filter, which is adispatch filter in this case.

Now consider the definition of class Distribution whichschedules requests to a pool of server objects. If a servicerequest is received by an instance of Distribution, itforwards this request to one of the server objects in itspool. If the selected server can not service the request,then the next object in the pool is tried. Distribution of amessage is terminated if the message can be accepted byone of the server objects, or all the server objects are triedonce for that message. If none of the objects can serve therequest, then the request must be handled by the firstserver. This will usually block the request until it can behandled by that server.

10

���� class�'LVWULEXWLRQ�interface��� comment�$�PHVVDJH�LV�VHQW�VXEVHTXHQWO\�WRDOO�VLWHV�LQ�WKH�VHW�XQWLO�LW�LV�DFFHSWHG��,I�LWLV�QRW�DFFHSWHG�E\�DQ\�RI�WKHVH��LW�ZLOO�EHEORFNHG�DW�WKH�ILUVW�VLWH�DIWHU�DOO���� methods��� GLVWULEXWH�0HVVDJH��returns�1LO���� SXW6LWH�VLWH��$Q\��returns�1LO���� inputfilters��� H[HFXWH�'LVSDWFK ^� �`���� end�

Figure 15. Interface definition of class Distribution.

Line 4 declares the method distribute. The methoddistribute accepts one argument of class Message. ClassMessage is used to represent messages in the system.Message provides methods to read and modify thearguments and the target of the message that it represents.If needed, a message object can be fired; if a messageobject is fired it turns into an execution of that message.The method Distribute is used to distribute the message,which is represented as its argument, to a set of objects.Line 5 declares the method putSite. This method is used toinitialize the set of server objects. Line 7 declares aDispatch filter, which accepts the distribute and putSiterequests.

In figure 16, the implementation of class Distribution isshown. The class maintains an ordered set of cooperatingserver objects in the instance variable sites (line 3). Todetect whether all the server objects have been attempted,a list of scheduled requests is maintained (scheduled, inline 3). If the request has not been tried for all serverobjects (line 10), the message is re-sent (fired) to the nextserver object in the sites list (lines 12-14). Otherwise themessage continues at the original sender (line 17). In thecase of DistributeBuffer the message will continue at thefilter following the meta filter. This is the dispatch filterthat dispatches the messages to the internal object of classBoundedBuffer. Because BoundedBuffer determines itsown synchronization constraints, the message may beblocked by the wait filter at the interface of the bufferobject. This was shown in the implementation of classBoundedBuffer in line 9 of figure 10.

5.5. Polymorphically composing synchronizations

This example demonstrates that multiplesynchronization specifications can be composedpolymorphically in different contexts. The classAtomicDistributedLocking combines the distributedsynchronization that was used previously for boundedbuffers with class Locking. At the same time an additionalsynchronization is composed which enforces atomicexecution of this distributed locking.

��� class�'LVWULEXWLRQ�implementation��� insvars��� VLWHV��VFKHGXOHG��2UGHUHG6HW���� ���and the declaration of the other instance variables��� methods��� SXW6LWH�VLWH�$Q\��returns�1LO���� begin��VLWHV�SXW�WDUJHW���end���� GLVWULEXWH�PHVVDJH�0HVVDJH��returns�1LO���� begin_���� if�the next site is not in the VFKHGXOHG list���� then���� add the message to the VFKHGXOHG list���� set the next site (in VLWHV) as the new target for the message���� and send the message to this new target���� end����� remove all entries in VFKHGXOHG for this thread���� let the message continue unmodified���� end������ end�

Figure 16. Implementation of class Distribution.

The first filter in this example, atomic, turns themessages that it accepts into an atomic transaction,which means that the execution of the messages becomesindivisible; either the execution is completely succesful(commit), or it is fully abandoned (abort).

One possible application of such a distributed lockingalgorithm is for locking a limited number of sharedresources; whenever a lock request is issued, it is tried tofind a currently unlocked server object, which will thenbe blocked. It is obvious that in the case of multipleconcurrent requests, atomicity of this distributed lockingalgorithm is important to ensure consistency.class�$WRPLF'LVWULEXWHG/RFNLQJ�interface

externalsORFN'LVWU�'LVWULEXWLRQ�

internalsORFNHU��/RFNLQJ�

conditionsORFNHU� �

methodsORFN�returns�1LO�XQORFN�returns�1LO�

inputfiltersDWRPLF���7ZR3/� �^�ORFNHU� �`�GLVWULEXWH/RFNV���0HWD� �^ /RFNHG� !�>ORFN@

��������������������������ORFN'LVWU�GLVWULEXWH�8QORFNHG� !�>XQORFN@

�������������������������ORFN'LVWU�GLVWULEXWH�`�H[HFXWH���'LVSDWFK� �^�ORFNHU� �`�

end�

Figure 17. Interface of class AtomicDistributedLocking.

The main point of this example is that a generic multi-server synchronization (Distribution) can be composedwith e.g. a BoundedBuffer class or a Locking class, eachdefining their own synchronization, and at the same time

11

with a specification that turns the involved messages intoatomic transactions.

5.6. Realizing ordered compositions

The example we use to demonstrate orderedcompositions is class ProtectedLockingBuffer, whichcomposes properties of class Login, class BoundedBufferand clas Locking:

��� class 3URWHFWHG/RFNLQJ%XIIHU�interface��� externals��� YHULILHU���/RJLQ���� internals��� EXIIHU���%RXQGHG%XIIHU���� ORFNHU���/RFNLQJ���� inputfilters��� RUGHU���(UURU� �^�YHULILHU� ���ORFNHU� ���������������������������EXIIHU� �`����QRWH�WKH�VHPLFRORQV�GHILQH�VHULDOL]DWLRQ��� ORFNHU�ORFN6\QF����� EXI�EXIIHU6\QF����� H[HFXWH���'LVSDWFK� �^�YHULILHU� �����������������������������EXIIHU� ��ORFNHU� �`����� end�

Figure 18. Interface part of classProtectedLockingBuffer.

The filter specifications in lines 8-11 are again thecrucial part of this class definition: the Error filter order inline 8 specifies ordering. This is achieved by specifying apattern of messages, separated by semicolons: “{ verifier.* ;locker.* ; buffer.* }”. A sequence of messages m1, m2, m3,.. that the object receives will only pass this filter if, andonly if, the messages are supported by respectively classLogin (m1, m4, m7, ..), BoundedBuffer (m2, m5, m8, .. ) andLocking (m3, m6, m9, ..). This means that the filter objectmaintains an internal state, designating which category ofmessages is expected next. The messages that areacceptable, simply pass to the next filter unmodified.Others will raise an error condition.

The two next filters (lines 9-10) specify composition ofsynchronization of class ProtectedLockingBuffer from theLocking and BoundedBuffer class, respectively. Finally,the dispatch filter execute in line 11 composes thebehavior of the ProtectedLockingBuffer from the threeexisting classes. The important thing to notice is that thecomposition of these different aspects is completelyorthogonal, in the sense that the specification of onesynchronization property does not prohibit thespecification of another.

6. Evaluation and conclusions

Most existing object-oriented concurrent languages donot provide composable synchronization mechanismsamong multiple server objects. We think that object-

oriented languages must support both single andmultiple-server synchronizations among objects in acomposable way.

The contribution of this paper is twofold. First, a newframework is introduced for the classification of themulti-server synchronization problems. Second, anobject-oriented model is defined to express thesesynchronization problems in a composable way. Theproblems of expressing multi-server synchronizationswere explained through a set of related examples. Thesame examples were also used to illustrate theapplicability of the composition-filters concept.

As explained in section 5, the composition-filtersmodel provides modular and orthogonal extensions to theconventional object model. Various filters can be definedto address different issues. For example, in figure 10, inthe definition of class BoundedBuffer, a wait filter wasused to express synchronization.

By adopting multiple filters, one can composesynchronization schemes of several objects. For example,in figure 12, the synchronization schemes ofBoundedBuffer and Locking were composed by cascadingtheir filters at the interface of class LockingBuffer.Similarly, since an object’s interface can be composedfrom internal and/or external objects, both inheritanceand delegation mechanisms can be specified. In thedefinition of SharedLockingBuffer, figure 13 illustrateshow synchronization distribution through delegation canbe implemented using composition filters.

Meta-filters can reify messages and pass them to ameta-level object. Since a meta-filter can be composedwith a wait filter, a meta-level behavior such asdistribution, can be composed with object’ssynchronization specification. This feature can be used tospecify cooperating synchronizations. The definition ofDistributedBuffer in figure 14 takes this approach.

An atomic filter can mark the received messages asatomic. After passing this filter, a message is executed asan atomic thread. The method that is activated throughsuch a message executes as an atomic transaction. Thismechanism allows the atomic transaction semantics to bepolymorphically composed with a set of messages, since afilter may allow different messages to pass through it.Polymorphic composition of synchronizations(serialization in this case), is illustrated byAtomicDistributedLocking in figure 17.

Finally, since filters are message processors, they canorder the messages that can be accepted by an object.This mechanism is useful in expressing orderedcompositions, such as ProtectedLockingBuffer in figure18.

In the application of the composition-filters model tomulti-server synchronization, we are currently

12

investigating a number of open problems. For example,cooperation among functionally compatible butprocedurally incompatible synchronizations is not trivial.One server object, for instance, can adopt two-phaselocking for serialization, and the other object may adoptan optimistic approach [19].

References

[1] G. Agha, An Overview of Actor Languages, ACMSIGPLAN Notices, Vol. 21, No. 10, Oct 1986, pp. 58-67

[2] M. Aksit & A. Tripathi, Data Abstraction Mechanisms inSina/ST, Proceedings OOPSLA ’88, ACM SIGPLANNotices, Vol. 23, No. 11, November 1988, pp. 265-275

[3] M. Aksit, J.W. Dijkstra & A. Tripathi, Atomic Delegation:Object-oriented Transactions, IEEE Software, Vol. 8, No.2, March 1991

[4] M. Aksit, L. Bergmans & S. Vural, An Object-OrientedLanguage-Database Integration Model: The Composition-Filters Approach, ECOOP ’92, LNCS 615, Springer-Verlag,1992

[5] M. Aksit, K. Wakita, J. Bosch, L. Bergmans & A.Yonezawa, Abstracting Object-Interactions UsingComposition-Filters, in: “Object-based DistributedProcessing”, R. Guerraoui, O. Nierstrasz & M. Riveill(eds.), LNCS 791, pp. 152-184, Springer-Verlag, 1993

[6] M. Aksit, J. Bosch, W. v.d. Sterren & L. Bergmans, Real-Time Specification Inheritance Anomalies and Real-TimeFilters, proceedings of ECOOP '94, LNCS 821, pp. 386-407, Springer-Verlag, 1994

[7] P. America, POOL-T: A Parallel Object-OrientedLanguage, in: “Object-Oriented Concurrent Programming”,eds. A. Yonezawa, M. Tokoro, The MIT Press, Cambridge,Mass. 1987, pp. 199-220

[8] P. America, A Parallel Object-Oriented Language withInheritance and Subtyping, Proceedings OOPSLA/ECOOP'90, ACM SIGPLAN Notices, Vol. 25, No. 10, October1990, pp. 161-168, October 1990

[9] L. Bergmans, Composing Concurrent Objects–ApplyingComposition Filters for the Development and Reuse ofConcurrent Object-Oriented Programs, Ph.D. Dissertation,University of Twente, June 1994.

[10] L.M.J. Bergmans and M. Aksit, ComposingSynchronization and Real-Time Constraints, Journal ofParallel and Distributed Computing, Vol. 36, No. 1, July1996, pp. 32-52

[11] J. van den Bosch & C. Laffra, PROCOL; A Parallel ObjectLanguage with Protocols, Proceedings OOPSLA ’89, ACMSIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 95-102

[12] J.P. Briot, Actalk: A Testbed for Classifying and DesigningActor Languages in the Smalltalk-80 Environment,Proceedings ECOOP ’89, Cambridge University Press,Nottingham, July 10-14, 1989, pp. 109-129

[13] D. Caromel, Concurrency: An Object-Oriented Approach,TOOLS-2, (eds.) J. Bezivin, B. Meyer & J.M. Nerson, pp.183-197, 1990

[14] Corradi & L. Leonardi, PO constraints as tools tosynchronize active objects, JOOP October 91, pp. 41-53

[15] D. Decouchant, P. Le Dot, M. Riveill, C. Roisin, X.Rousset de Pina, A Synchronization Mechanism for anObject-Oriented Distributed System, Proceedings of the11th IEEE Conference on Distributed Computing Systems,May 1991

[16] S. Frølund, Inheritance of Synchronization Constraints inConcurrent Object-Oriented Programming Languages,Proceedings ECOOP '92, Springer-Verlag, Utrecht, TheNetherlands, June/July 1992, pp. 185-196

[17] S. Frølund & G. Agha, A Language Framework for Multi-Object Coordination, Proceedings ECOOP '93, Springer-Verlag, Kaiserslautern, Germany, July 1993, pp. 346-360

[18] N. Francez et al, Script: A Communication AbstractionMechanism and Its Verification, Science of ComputerProgramming, Vol. 6, No. 1, pp. 35-88, 1986.

[19] R. Guerraoui, Atomic Object Composition, in: M. Tokoro& R. Pareschi (eds.), “Object-Oriented Programming”,Proceedings of ECOOP ‘94, Bologna, July 1994, pp.118-138

[20] T. Haerder & A. Reuter, Principles of Transaction-Oriented Database Recovery, ACM Computing Surveys,Vol. 15, No. 4, December 1983, pp. 287-317

[21] R. Helm, I. Holland & D. Ganghopadhyay, Contracts:Specifying Behavioral Compositions in Object-OrientedSystems, OOPSLA '90, pp. 169-180, 1990.

[22] I.M. Holland, Specifying Reusable Components UsingContracts, ECOOP '92, LNCS 615, pp. 287-308, Utrecht,June 1992.

[23] Y. Ishikawa & M. Tokoro, A Concurrent Object-OrientedKnowledge Representation Language Orient84/K: ItsFeatures and Implementation, Proceedings OOPSLA '86,ACM SIGPLAN Notices, Vol. 21, No. 11, November1986, pp. 232-241

[24] D.G. Kafura & K.H. Lee, Inheritance in Actor BasedConcurrent Object-Oriented Languages, ECOOP '89, pp.131-145

[25] H. Lieberman, Using Prototypical Objects to ImplementShared Behavior, Proceedings OOPSLA '86, ACMSIGPLAN Notices, Vol. 21, No. 11, November 1986, pp.214-223

[26] K.-P. Löhr, Concurrency Annotations for ReusableSoftware, Communications of the ACM, Vol. 36, No. 9,September 1993, pp. 81-89

[27] V. Lopes & K. J. Lieberherr, Abstracting Process-to-Function Relations in Concurrent Object-OrientedApplications, proceedings of ECOOP '94, LNCS 821, pp.81-99, Springer-Verlag, 1994

[28] S. Matsuoka, T. Watanabe & A. Yonezawa, Hybrid GroupReflective Architecture for Object-Oriented ConcurrentReflective Programming, ECOOP '91, LNCS 512, pp. 213-250, Springer-Verlag, 1991

[29] S. Matsuoka & A. Yonezawa, Inheritance Anomaly inObject-Oriented Concurrent Programming Languages, in:“Research Directions in Concurrent Object-OrientedProgramming”, (eds.) G. Agha, P. Wegner & A.Yonezawa, MIT Press, April 1993, pp. 107-150

13

[30] S. Matsuoka, K. Taura & A. Yonezawa, Highly Efficientand Encapsulated Re-use of Synchronization Code inConcurrent Object-Oriented Languages, ProceedingsOOPSLA ’93, ACM SIGPLAN Notices, Vol. 28, No. 10,October 1993, pp. 109-126

[31] J. Meseguer, Solving the Inheritance Anomaly inConcurrent Object-Oriented Programming, ProceedingsECOOP ’93, Springer-Verlag, Kaiserslautern, Germany,July 1993, pp. 220-246

[32] Neusius, Adapting Synchronization Counters to theRequirements of Inheritance, OOPS Messenger, Vol. 2, No.4, October 1991

[33] O.M. Nierstrasz, Active Objects in Hybrid, ProceedingsOOPSLA ’87, ACM SIGPLAN Notices, Vol. 22, No. 12,December 1987, pp. 243-253

[34] Tomlinson & V. Singh, Inheritance and Synchronizationwith Enabled-sets, Proceedings OOPSLA ’89, ACMSIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 103-112

[35] T. Watanabe & A. Yonezawa, Reflection in an Object-Oriented Concurrent Language, Proceedings OOPSLA ’88,ACM SIGPLAN Notices, Vol. 23, No. 11, November 1988,pp. 306-315

[36] Yonezawa et al., Modeling and Programming in an Object-Oriented Concurrent Language ABCL/1, in Object-Oriented Concurrent Programming, (eds.) A. Yonezawa &M. Tokoro, MIT Press, pp. 55-89, 1987