Object Synchronizer: A Design Pattern for Object Synchronization

Transcription

1 Synchronizer: A Design Pattern for António Rito Silva 1, João Pereira 2 and José Alves Marques 1 1 INESC/IST Technical University of Lisbon, Rua Alves Redol n o 9, 1000 Lisboa, PORTUGAL 2 INRIA, Domaine de Voluceau, Rocquencourt, B.P. 105, Le Chesnay Cedex, FRANCE Rito.Silva@acm.org, Joao.Pereira@inria.fr, jam@inesc.pt This pattern was workshopped at the European Conference of Pattern Languages of Programs (EuroPLoP96), Kloster Irsee, Germany, July, Abstract This paper describes the Synchronizer pattern which decouples object synchronization from object functionality. This pattern supports several synchronization policies and their customization. This pattern is used when invocations to an object need to be controlled in order to preserve its consistency. The solution described by this pattern provides encapsulation, modularity, extensibility and reuse of synchronization policies. 1. Intent The Synchronizer pattern abstracts several object synchronization policies. It decouples object synchronization from object functionality. 2. Also Known As Concurrency Control. Serialization. 3. Motivation 3.1. Example Consider the design of a Cooperative Drawing Application allowing cooperative manipulation of graphical documents. Users at different terminals can simultaneously access the same graphical document and changes made to a local view are immediately propagated to other local views. Due to the cooperative characteristics of the application a shape can be made private, publicly readable or publicly writable. A shape is private when it is only visible to the user that has created it: its owner. A shape is publicly readable when it is visible to all users but only its owner can update it. A shape is publicly writable when any user can see and modify it. A possible architecture for such an application contains several client applications having their own objects (application space) and sharing a set of domain objects (domain space) which may be kept in a data store (persistent space). The application space has interface objects, e.g scrollbars and shapes; the domain space has shared objects, e.g. shapes data; and the persistent space stores documents, e.g. a graphical document including its shapes data Problem Client applications execute operations that invoke methods on shape objects. Invocations on a non-private shape object must be controlled either because it is a publicly readable shape where update invocations from non-owners should return an error; or because it is a publicly writable shape where simultaneous invocations by different client applications are liable to result in corruption of the shared shape s state. Traditional solutions for object synchronization use: The persistent space s locking mechanisms to synchronize invocations to shared resources. However, a shared object may just be volatile and the effort to make it persistent may result in unacceptable overhead. Another issue is that the supported locking mechanisms may not be suitable for the synchronization needs of the application. mechanisms, as semaphores [1] and monitors [2], to synchronize accesses. However, this results in code tangling which forbids, both functionality and synchronization independent reuse. For instance, a shape s functionality code should be the 1

2 same for private, publicly readable or publicly writable shapes Forces An object-oriented solution for the object synchronization problem must resolve the following forces: Extensibility requires abstraction of synchronization policies. It is not possible to find an optimal policy for all situations: policies should be customizable. The most suitable policy depends on the domain object and its operations semantics. For instance, some domain objects are frequently accessed, thus requiring a pessimistic policy, whereas others are not, making the use of an optimistic policy more efficient. Modularity requires separation of object synchronization from object functionality. This orthogonality allows synchronization policy switching with no repercussions on other components, as well as incremental introduction of synchronization. Encapsulation requires the synchronization part of an object to be placed within the object itself rather than spread out among its clients. This places synchronization responsibility within the object, thereby avoiding client negligence. Reusability requires separate reuse of functionality and synchronization code. It should be possible to independently reuse both synchronization code and functionality code. For instance, a shape functionality code is reused for private, publicly readable and publicly writable shape classes Solution Figure 1 sketches a solution for the synchronization of a Shape object. Client Shape Interface moveby() Policy precontrol() postcontrol() Shape moveby() synchronization->precontrol() shape->moveby() synchronization->postcontrol() Figure 1. Synchronized Shape. Invocations on a Shape are intercepted by a Shape Interface that can let them proceed or can delay or reject them. The Shape Interface synchronizes invocations delegating on Policy. Operations precontrol and postcontrol of the Policy control the order of invocations according to a given synchronization policy. Extensibility is achieved by providing different implementations of the Policy. Each implementation provides a specific synchronization semantics. Actually, due to synchronization complexity, Policy class is a Façade [3] encapsulating several synchronization objects. Modularity is achieved through the implementation of synchronization in Policy class and so it is decoupled from Shape. Encapsulation is achieved because the Shape Interface isolates synchronization from the Client. Reusability is achieved because a Shape objects can be associated with different Policy objects. This allows independent reuse of Shape and Policy classes. 4. Applicability Use the Synchronizer pattern when: Invocations to an object must be controlled to preserve its consistency - invocations must be controlled according to a synchronization policy. It is premature to decide on which object synchronization policy to use. - At initial stages of the development process it may be too early to choose a specific policy. Moreover it should be possible to test several policies before choosing. Different synchronization policies may be used by different objects of a class - different synchronization and sharing semantics 1 are often required by applications, e.g. groupware systems. 5. Structure and Participants The UML [4] class diagram in Figure 2 illustrates the structure of the Synchronizer pattern. The main participants in the Synchronizer pattern are: 1 For objects of the same or different classes. 2

3 Client Interface m() Synchronizer precontrol() postcontrol() invocations * Functional m () status require() postguard() pre() post() require, preguard and postguard. For validation purposes, these operations may use their local synchronization data, the synchronization data of other invocations (contained in other objects) and the object synchronization data (contained in object ). Operations preguard and postguard verify whether an invocation is compatible with other concurrent invocations while operation require controls access according to the object state. Operations pre, exec, post, commit and abort update synchronization data.. Provides global object synchronization data. It may use the Functional to get synchronization data. Figure 2. Synchronizer Pattern Structure. Client. Requires a service from Functional, by invoking one of its operations through Interface. Functional. Contains the functionality code and data. Accesses to it should be synchronized. Interface. Is responsible for the synchronization of invocations to the Functional using the services provided by the Synchronizer. It creates a object for each invocation. It invokes precontrol before invocation proceeds on the Functional and postcontrol after. Synchronizer. It decides whether an invocation may continue, stop or should be delayed (returns values, ERROR and ). Operations precontrol and postcontrol control the order of invocations. The former enforces pessimistic synchronization policies while the latter enforces optimistic synchronization policies.. Identifies the invocation and contains its current status which can be: pre-pending, executing, post-pending, committed and aborted (attribute status with values PRE, EXEC, POST, COMMIT and ABORT). It also contains a queue of predicates: invocations. Defines the synchronization semantics of an invocation through operations 6. Collaborations The UML sequence diagram in Figure 3 illustrates collaborations between objects involved in the Synchronizer pattern. CREATE PRE-CONTROL POST-CONTROL EXECUTION a Interface m() new() *xstatus== xstatus = precontrol() m () *xstatus== xstatus = postcontrol() a Synchronizer xstatus = require() xstatus = xstatus = postguard() [xstatus==] post() a pre() a Functional Figure 3. Synchronizer Pattern Collaborations. Four collaboration phases are described: 1. CREATE. Corresponds to an access made by a Client object. This phase creates a object. Its status is initialized to PRE. Operation pre may update policy-specific synchro- 3

4 nization data with information about the invocation category and its argument values. 2. PRE-CONTROL. This phase synchronizes the invocation before accessing the Functional (operations require and preguard). An ERROR value may be returned, preventing the execution of the client invocation, otherwise execution is delayed or resumed. If or ERROR values are returned, the status is updated to, respectively, EXEC or ERROR by operations exec and abort. These operations may also update policy-specific synchronization data in and objects. This phase is repeated while precontrol returns. 3. EXECUTION. The invocation executes on the Functional. This phase occurs only if the previous phase returned. 4. POST-CONTROL. This phase verifies if an invocation already done (in state EXEC or POST), is correctly synchronized with other concurrent invocations. The verification protocol (operation postguard) is similar to that of the previous phase. Operations post, commit, and abort, on the object, set the status value to POST, COMMIT, and ABORT respectively. Additionally, they may update policy-specific synchronization data in and other objects. This phase is repeated while postcontrol returns. Operations pre, precontrol and postcontrol must be executed in mutual exclusion since any interference may result in synchronization data corruption. 7. Consequences The Synchronizer pattern has the following advantages: Isolates synchronization code from client objects, allowing the shared object to enforce a consistent synchronization policy. Clients can ignore whether an object is shared or not, which simplifies them. Encapsulation is achieved by placing the synchronization code within the synchronized object such that client objects can invoke the Interface ignoring how synchronization is achieved. Separates functionality code from synchronization code, allowing separate development, test and reuse. code is encapsulated by classes Synchronizer, and. Abstracts several synchronization policies, like readers/writers, synchronization counters, or dynamic priority. The policies can be either optimistic or pessimistic. This extensibility is achieved by specializing classes Synchronizer, and. This pattern has the following disadvantage: Increases the number of classes and objects. More classes and objects are needed than in a solution based on synchronization mechanisms as semaphores. However, due to code tangling, this solution is more complex and error prone. 8. Implementation 8.1. Customization of Policies Programmers customize synchronization policies by defining specific subclasses of Synchronizer, and. There are several ways to implement Synchronizer pattern. This section discusses major issues and possibilities. Pessimistic and Optimistic Policies. policies can use two different generic algorithms: pessimistic, when the object is expected to have high contention; and optimistic, when the level of contention is expected to be low. These two perspectives are coded in subclasses of Synchronizer as illustrated in Figure 4. Pessimistic policies control invocations during the PRE-CONTROL phase by verifying compatibility with other objects (operations require and preguard). During POST-CONTROL, pessimistic policies do not verify compatibility, since synchronizations were already verified (thus operation postguard is not invoked). Optimistic policies do not control invocations during the PRE-CONTROL phase. Nevertheless, operation require must be invoked to verify whether an object s state allows invocation execution, e.g. it may not be possible to get a value from an empty buffer. Afterwards, during the POST-CONTROL phase it is necessary to verify if the invocation is compatible with other executing and terminated invocations (operation postguard). 4

5 precontrol() a Pessimistic Synchronizer xstatus = require() xstatus = a precontrol() a Optimistic Synchronizer xstatus = require() a Optimistic Readers/Writers. Class and sequence diagrams described in Figure 6 show the specialization of for an optimistic readers/writers synchronization policy. Read/Write category abort postcontrol() postcontrol() xstatus = postguard() [xstatus==] post() [category==read] getcategory() setabort() [category==write] postguard() ERROR [abort] [NOT abort] Read Write a Read a Write Figure 4. Pessimistic and Optimistic Synchronizers. *invocations c = getcategory() *invocations [s==exec] setabort() [s==exec && c==write] setabort() Pessimistic Readers/Writers. Class and sequence diagrams presented in Figure 5 show the specialization of for a pessimistic readers/writers synchronization policy. a Read [category==read] *invocations Read Read/Write category getcategory() Write [category==write] a Write *invocations Figure 6. Optimistic Readers/Writers Policy. Operation postguard of Read/Write objects returns ABORT if the abort attribute has the value TRUE. Operation commit of Read sets the attribute abort of all Write objects whose status is EXEC to TRUE. Operation commit of Write sets the attribute abort of all predicate objects whose status is EXEC to TRUE. We assume that each access to the shared object is done in a private copy. If afterwards the invocations terminates with success, we actualize the shared object. This corresponds to the deferred-update recovery policy of the Recovery pattern [5]. s = getcategory() [s==exec && c==write] [s===exec] Figure 5. Pessimistic Readers/Writers Policy. This solution distinguishes between read and write invocations. A generic synchronization predicate Read/Write defines the invocation categories, e.g. READ and WRITE. Operation preguard of Read returns if one of the invocations predicates is a Write with status value EXEC, i.e., there is another client invocation that is accessing the shared object in write mode. Operation preguard of Write returns if there is an invocations predicate with status value EXEC. Dynamic Priority Readers/Writers. The pessimistic readers/writers policy allows starvation of writers. To solve this problem, whenever a read starts executing, the priority of pending write invocations is incremented. Class and sequence diagrams presented in Figure 7 show the specialization of for a dynamic priority readers/writers synchronization policy. Operation preguard of Read returns if there is a Write with MAX priority and operation exec of Read increments the priority of Write. Producer/Consumer. Class and sequence diagrams presented in Figure 8 show the specialization of and for a producer/consumer synchronization policy. 5

6 [category==read] Read a Read Read/Write category getcategory() *invocations c = getcategory() [category==write] Write priority getpriority() incpriority() a Read a Write *invocations c = getcategory() [s==pre && c==write] incpriority() *invocations c = getcategory() Specializations of class can implement synchronization counters using an attribute for each counter. Moreover, it is necessary that operations pre, exec, post, commit and abort of class invoke the to update the attribute values accordingly. Note that the previously described readers/writers policies could have been written using synchronization counters. [c==write] p = getpriority() [(s==exec && c==write) (s==pre && c==write && p==max)] [c==write] p = getpriority() [(s==exec) (s==pre && c==write && priority<p)] 8.2. Separation of Functional and Variables Figure 7. Dynamic Priority Readers/Writers Policy. Producer/Consumer category getcategory() Producer/consumer policies can have different implementations of class Buffer : this class either accesses the functional object to obtain synchronization information or holds and manages its own synchronization variables. Top and bottom sequence diagrams presented in Figure 9 show the two possible implementations. [category==produce] [category==consume] Buffer Produce Consume isempty() isfull() Functional Functional b = isfull() num = getnumitems() b = isempty() num = getnumitems() a Produce require() b = isfull() a Consume require() b = isempty() TRUE FALSE [num==size] [num<size] TRUE FALSE [num==0] [num>0] [b==true] [b==false] [b==true] [b==false] a Produce a Consume incnumitems() decnumitems() Figure 8. Producer/Consumer Policy. Class Buffer contains information about the number of items in the buffer. Operation require of Produce returns if the synchronization information contained in Buffer indicates that the buffer is full. Operation require of Consume returns if the synchronization information contained in Buffer indicates that the buffer is empty. Note that operations preguard or postguard should be redefined if state corruption can result from the concurrent execution of produce or consume operations. Counters. Several concurrent objectoriented languages, e.g. Guide [6], provide synchronization counters which count, for each type of invocation, the number of pending, executing and finished invocations. Figure 9. Variables. The top solution reduces concurrency, because synchronization verification conflicts with invocation execution, e.g. a variable written during an invocation execution is read during the PRE-CONTROL phase of another invocation. The bottom solution completely separates the functional variables from the synchronization variables. Besides the increment in concurrency, the bottom solution allows the independent reuse of the synchronization policy because it does not depend on the functional object interface. For instance, if programmers only distinguish among consume and produce invocations they can use the presented synchronization classes for producer/consumer policies. By using customized synchronization classes, programmers of the functional class do not need to be aware of the structure and collaborations of the Synchronizer pattern. 6

7 8.3. Transparency Transparency can be achieved if the Functional and the Interface have the same interface. In that situation the Client can ignore whether the object is synchronized or not. Nevertheless, there are situations where the Client must be aware of synchronization. For instance, the Client can receive an error if the invocation is rejected. In this situation, transparency can be relaxed by enriching the Interface according to the Client s synchronization requirements. Although there is transparency loss, this does not imply break of encapsulation: synchronization is still not the client s responsibility Concurrency Two policies of object concurrency are considered: active object and concurrent object. Active objects have an internal activity that selects and executes invocations, while invocations to concurrent objects can execute concurrently, for instance, using the caller s activity. A synchronized object can either be active or concurrent. If it is an active object its Interface encapsulates a single internal activity which accesses the synchronization objects and the functional object. On the other hand, if it is a concurrent object the synchronization objects and the functional object can be concurrently accessed by several activities. So, because of object concurrency policies, object synchronization requires different implementations of mutual exclusion and activity delay/resume services. Both implementations are orthogonal to synchronization code. Concurrent. A mutex object is used to support mutual exclusion of synchronization code. A condition object is used to block the activity associated with an invocation if is returned. Active. The design of an active object is described in [7]. It contains a queue of method objects representing pending invocations. A method object has the code associated with an invocation. Active objects use a scheduler object to select and execute pending method objects. Mutual exclusion of synchronization code is provided by the internal scheduler thread. Activity delay is implemented by moving the invocation to the end of the queue. 9. Sample Code This section presents the implementation of shape objects belonging to the Cooperative Drawing Application. In the Cooperative Drawing Application accesses to shared shapes need to be synchronized. The implementation of private, publicly readable and publicly writable shapes is described for pessimistic policies. Class Shape represents a shape. It knows its data and how to update it when the shape is moved (operation moveby). The interface definition is as follows. class Shape public: Shape( data); Shape(); // Move - update data void moveby(point delta); // Read data get(); private: // Shape data data; ; Class Shape implements a private shape since its objects are not shared. To support public shapes class Shape Interface, subclass of Interface, is defined. The synchronization associated with operation moveby is shown below. This class uses a concurrent object policy and so Mutex and Condition objects are used to support mutual exclusion in the synchronization code and invocation delays and resumes. void ShapeInterface::moveBy(Point delta) X_Status status; // creates a predicate MoveByPred * pred = new MoveBy(); // pre-control do // begin mutual exclusion mutex_.acquire(); // verify compatibility status = synchronizer_->precontrol(pred); // end mutual exclusion mutex_.release(); // if there are incompatibilities wait if (status == ) condition_.wait(); while (status == ); if (status == ) // invocation proceeds on functional object shape_ shape_->moveby(delta); else return; // post-control do // begin mutual exclusion mutex_.acquire(); 7

8 // verify compatibility status = synchronizer_->postcontrol(pred); // end mutual exclusion mutex_.release(); if (status == ) condition_.wait(); else // only if or ERROR // awake pending invocations condition_.broadcast(); while (status == ); Note that, since pre-control and post-control code fragments are independent of a particular invocation it could be defined as two protected operations of class Interface. For each synchronized operation, these generic operations could be invoked receiving a object as argument. Particular synchronization policies are defined by classes MoveBy and Get which are subclasses of Shape. Shape inherits from and defines two invocation categories: MOVE and GET. // Generic shape predicate class Shape : public public: Shape(int cat) : cat_(cat) Shape() // returns category int getcat() return cat_; // other operations to be redefined //... private: // Invocation categories: MOVE and GET CAT cat_; ; A publicly readable shape defines Get to allow concurrent execution of get invocations. Class MoveBy restricts invocations of moveby to the shape s owner and forbids concurrent execution of moveby invocations. Operation get is a read operation while moveby is a private write operation. // prevents conflicts with executing moveby X_Status Get:: // iterator for predicates PIterator iter(sync_); *pred; while (pred = iter.next(), pred!= 0) // there are moveby invocations executing if ((pred->getstatus() == EXEC) && (((Shape*)pred)->getCat() == MOVE)) // conflict return ; // no conflict return ; // prevents conflicts with executing get and moveby X_Status MoveBy:: // iterator for predicates PIterator iter(sync_); *pred; while (pred = iter.next(), pred!= 0) // there are invocations executing if ((pred->getstatus() == EXEC)) // conflict return ; // no conflict return ; // requires that invoker is shape s owner X_Status MoveBy::require() // InvOwner global function returns invoker id // sd_ is an instance of a // subclass which contains the shape s owner if (InvOwner() == sd_->owner()) return ; return ERROR; A publicly writable shape allows any user to move the shape. The synchronization predicates are identical to publicly readable shape s synchronization predicates except for predicate MoveBy which has to relax the require operation. // publicly writable moveby require // any user can move the shape X_Status MoveBy::require() return ; 10. Known Uses The need for object synchronization is widely recognized in concurrent programming languages, objectoriented databases, and distributed object systems. Most solutions to this problem restrict the supported number of policies and do not decouple synchronization from concurrency. Distributed systems, e.g. Arjuna [8] and Hermes/ST [9], use the Synchronizer pattern encapsulated by platform mechanisms. Arjuna defines two classes, Lock and LockManager: class LockManager supports a pessimistic synchronization policy while class Lock contains object-specific information. Programmers only need to redefine Lock operations. In Hermes there are two kinds of synchronization: implicit and explicit. Implicit synchronization offers a transparent pessimistic policy to synchronize invocations with attribute granularity, while explicit synchronization uses the object s state. Explicit synchronization defines class ProgrammableLock which has two operations: isscheduable and iscompatiblewith. The former uses the object s state while the latter defines the compatibility between operations. Scheduling predicates were defined in [10] in the context of a concurrent object-oriented language. This language 8

9 contains identical abstractions and synchronization expressibility as Synchronizer pattern. The Synchronizer pattern is integrated with other design patterns: Concurrency and Recovery [5]. It is implemented as part of an object-oriented framework that supports object concurrency, synchronization and recovery [11]. This framework is publicly available from ars/dasco. 11. Related Patterns The Active pattern [7] decouples operation execution from operation invocation in order to simplify synchronized accesses to a shared resource. The active object has an internal thread which dispatches pending operations. The internal thread can do some synchronization when selecting the next operation to dispatch. The Synchronizer abstracts synchronization policies independently of a particular implementation of object concurrency such as active object. The Recovery pattern [5] abstracts several policies for object recovery. Combined with the Synchronizer pattern it allows implementation of synchronization policies that need to recover the object s state, e.g. optimistic policies. However, some combinations of synchronization and recovery policies are not possible or, although possible, penalize performance. It has been proven that some compatibility relations between invocations require a particular kind of recovery policy [12], e.g. forward commutativity requires an update-in-place recovery policy. Common combinations are optimistic policies and deferredupdate recovery policies, where simultaneous invocations proceed on a copy of the object (optimized abort), and pessimistic with update-in-place recovery policies (optimized commit), where invocations proceed on the same object. The Proxy pattern [3] is used to control accesses to the Functional. The Functional corresponds to RealSubject while the Interface corresponds to Proxy. The Functional does not know anything about the Interface. The Strategy pattern [3] is used between the Interface and the Synchronizer. It provides the configuration of Interface with synchronization policies. References [1] E. W. Dijkstra. Cooperating Sequential Processes. In F. Genuys, editor, Programming Languages. Academic Press, [2] C. A. R. Hoare. Monitors: An Operating System Structuring Concept. Comunications of the ACM, 17(10), October [3] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable - Oriented Software. Addison Wesley, [4] Martin Fowler and Kendall Scott. UML Destilled: Applying de Standard Modeling Language. Addison-Wesley, [5] António Rito Silva, Joao Pereira, and José Alves Marques. Recovery. In Robert Martin, Dirk Riehle, and Frank Buschman, editors, Pattern Languages of Program Design 3, chapter 15, pages Addison-Wesley, [6] D. Decouchant, P. Le Dot, M. Riveill, C. Roisin, and X. Rousset de Pina. A synchronization mechanism for an object-oriented distributed system. In Proceedings of the 11th International Conference on Distributed Computing Systems, pages , Arlington, Texas, USA, May [7] R. Greg Lavender and Douglas C. Schmidt. Active : an Behavioral Pattern for Concurrent Programming. In John M. Vlissides, James O. Coplien, and Norman L. Kerth, editors, Pattern Languages of Program Design 2, pages Addison-Wesley, [8] Santosh K. Shrivastava, Graeme N. Dixon, and Graham D. Parrington. An overview of the arjuna distributed programming system. IEEE Software, pages 66 33, January [9] Michael Fazzolare, Bernhard G. Humm, and R. David Ranson. Concurrency control for distributed nested transactions in hermes. International Conference for Concurrent and Distributed Systems, [10] Ciaran McHale, Bridget Walsh, Sean Baker, and Alexis Donnelly. Scheduling s. In Mario Tokoro, Oscar Nierstrasz, and Peter Wegner, editors, Proceedings of the ECOOP 91 Workshop on -based Concurrent Computing, volume 612, pages Springer-Verlag, [11] António Rito Silva. Development and Extension of a Three- Layered Framework. In Saba Zamir, editor, Handbook of Technology, chapter 27. CRC Press, [12] William Weihl. The Impact of Recovery in Concurrency Control. Journal of Computer and System Sciences, 47(1): , August Acknowledgments. Thanks to our colleagues Pedro Sousa, David Matos, Luís Gil and João Martins. We also thank the participants of the EuroPLoP 96 writers workshop on Distribution. 9