Cooperative Concurrency Control

Institut für Mathematische Maschinenund Datenverarbeitungder Friedrich-Alexander-UniversitätErlangen-Nürnberg Lehrstuhl für Informatik IV(Betriebssysteme)Cooperative Concurrency ControlRainer PruyUniversity Erlangen-NürnbergInstitut für mathematische Maschinen und Datenverarbeitung IVLehrstuhl für BetriebssystemeMartensstraße 1D-W-8520ErlangenGermanyphone: +499131 85-7909fax: +49913139388email: pruy@informatik.uni-erlangen.deAbstractToday research on concurrency in object systems concentrates on concurrent objects. If onehas to address situations involving concurrency control conditions spanning several objects one isstill on one’s own. This paper illustrates the need to be able to describe concurrency control in distri-buted situations. It presents the concept of cooperative concurrency control as a first step in addres-sing this problem. Cooperative concurrency control separates functional behaviour and concurrency control into individual objects interacting to achieve the behaviour of a single concurrent object. Asthis approach is based on object interaction it naturally extends to distributed situations.Keywordsconcurrency, distribution, object interaction, cooperation, composition1§1IntroductionExperience has taught that integrating concurrency with the notion of objects is not an easy task. Research in this field focused on the problem of concurrent objects. The main reason behind this is the observation that the need for concurrency control is evident only at the level of individual objects.An important concept of object systems is encapsulation. It prevents the implementation of an object from being visible and accessible from outside that object. Instead the behaviour of an object is specified in a more abstract description called interface. This provides for independen-ce of the clients of an object from the actual implementation.In a sequential context the interface needs only to describe the functional aspects of the beha-viour of an object. In the presence of concurrency, the interface, in addition to this functional aspect, has to reflect dynamic behaviour. In recent ongoing approaches objects are assumed to be concurrent and dynamic behaviour is specified in terms of concurrency constraints applied to method invocations ([Caro90],[Geib92],[Frøl92]).Inheritance, according to [Wegn87], is the defining property of object orientation. It formalizes incremental modifications as a key means to achieving reuse. Recent works (e. g. [BeAk92],[-Mats90], [Shiba91]) concentrated on integrating concurrency control with inheritance. The re-sults can be summarized by the following two requirements for object interface descriptions:–separation of concernsThe different aspects of the behaviour of an object should be specified using sepa-rate descriptions allowing for independent modifications of these descriptions. Inthe presence of concurrency there are at least two such aspects, namely functionalbehaviour and dynamic behaviour. If there are independent aspects of dynamic be-haviour even these should be expressed using separate descriptions.The overall behaviour of an object results from a combination of all behaviouralaspects. Incremental modification of individual aspects requires clean interfacesbetween the separate descriptions.–flexible modelling of an object-state needed for concurrency controlEncapsulation prevents concurrency constraints from referring to state informationinternal to the object. Thus, needed state information has to be modelled at the in-terface level. The limitations of the underlying principles used in this modellingprocess restrict the set of concurrency constraints, which can be expressed.The aforementioned approaches concentrate on concurrency within a single object. Later in this paper it is stated that handling concurrency internal to objects is not sufficient. Currently there are no approaches addressing concurrency problems involving several objects. [Holl92] and [John91] among others propose concepts to specify multi-object configurations. However, they concentrate on functional aspects of object composition. They do not account for additional concurrency constraints arising from such composition. Section 2 will discuss distributed con-2§ 2Concurrency in distributed environmentscurrency and the solutions available with current object systems. A model for concurrency con-trol will be presented in section 3. Based on this model an implementation strategy is developed, which is outlined in section 4.2Concurrency in distributed environmentsObjects provide a natural way for expressing distribution. They already describe a distributed system. In this system the processing of methods models local operations and object interaction models the communication among (distributed) components. By packaging objects during the process of configuring a system, coarser distributional situations can be reflected. Handling con-currency only in the (local) context of individual objects ignores the need for controlling con-current execution under constraints spanning several objects.A standard answer to this problem is delegating responsibility to alternate concepts. Usually tr-ansaction concepts are mentioned. However, transactions are not well suited for handling gene-ral concurrency control problems. They are intended for achieving data consistency and use the concept of mutual exclusion to achieve this goal. If concurrency constraints include flow control or operation sequence requirements, transactions do not aid in formulating a solution.An alternate approach to handling concurrency control in distributed situations is to introduce a central object which manages concurrency constraints. Such an object requires only object in-ternal concurrency control mechanisms. Therefore this approach can be followed with available object systems. It voids, however, any possibility of exploiting distribution. For example, it is no longer possible to optimize placement of objects within a system for communication costs as any access to the objects involved in a distributed concurrent constellation has to get through this central concurrency control object. A simple example will illustrate the problem.In an object environment it is easy to construct a buffer with a FIFO behaviour based on object references. This allows objects which are currently elements of that buffer to remain at their lo-cation within the object system. Figure 2.1 pictures a linked list implementation of such a buffer. Usually the behaviour of such a buffer would be implemented using a single object. It would probably use two instance variables, in the example called fifo_head and fifo_tail, for managing the linked list of elements. Now, if the programmer knows that retrieve always gets called from a certain point within the system and store always gets called from a different point, he or she may try to optimize communication costs by spliting FIFO into a fifo_head and a fifo_tail object and collocating each of these objects with the object(s) using it. However, the two objects fifo_head and fifo_tail together exhibit the same behaviour as the FIFO object. The concurrency constraints are the very same. In both cases concurrency control has to serialize calls to retrieve and store as soon as the buffer contains, at most, one element. But this uncovers an inconsistency. The same functional behaviour with identical concurrency control requirements requires totally different descriptions according to whether distribution has to be considered or not. Currently there is no possibility for reuse among a distributed and a non-distributed solution to the FIFO buffer problem. While this may be una-voidable in many cases for the pure functional behaviour, as the notion of locality is different3Abb. 2.1Example: FIFO bufferbetween distributed and non-distributed descriptions, concurrency control should not directly be affected by such a design decision. Decisions made by concurrency control are the same whether functional behaviour is implemented using a single object (FIFO) or several objects (fifo_head and fifo_tail).The example above makes obvious the need for concurrency control which are able to handle constraints spanning several objects: when the combined behaviour of these objects constitutes a behaviour which would be specified using a single object as long as distribution is not to be considered. The example also illustrates the observation that concurrency constraints do not de-pend on the actual implementation of the corresponding functional behaviour. In the same way a functional description just relies on a specific behaviour of concurrency control without being interested in the details of how this behaviour is being achieved.This observation can be extended to object structures whose behaviour can not easily be captu-red by specifying a single object, as is the case when that behaviour is built on distribution. It can be viewed as a special case of the principle of separation of concerns. It also leads to the conclusion that this principle is important not only in the case of specifying behaviour of a sing-le object but also in the case of describing concurrent behaviour of object structures.3 A model for concurrency controlNow, that the problem has been outlined, it is necessary to look at how concurrency control ope-rates. Figure 3.1 pictures the dependencies involved with concurrency control. This structure can be observed even in current declarative approaches to concurrency control ([Deco89],[-Neus91],[McHa91]). As a first step it will be interpreted in terms of single object concurrency. 4In this context concurrency is recognizable as concurrent requests pending for processing at the encapsulation border of an object. Execution of these requests is controlled by concurrency constraints as specified at the interface of that object.Concurrency constraints are expressed in terms of an abstract state. However, this abstract state can in no way refer to information from the internal state as this information is hidden behind the encapsulation border.In order to solve this dilemma one could try to infer the current abstract state from the knowled-ge of the initial state and monitoring requests of an object. Such monitoring, though, is inaccu-rate due to indeterminism resulting from concurrent execution of requests. As long as such in-determinism does not occur, state inference could be considered a possibility.The figure above is intended to suggest a different solution. While the interface is not allowed to violate encapsulation nor to access the internal state defined by the actual implementation, this implementation is allowed to provide information about that internal state for its environ-ment. This means that a programmer, during implementation of the behaviour of an object, also has to define how this implementation maps into the behaviour specified at the interface.As, during implementation, a programmer already has to consider whether this implementation really conforms to the interface specification it does not seem to be a problem to make him or her state this conformance explicitly. This can be accomplished by providing a mapping from internal state to abstract state. It is, however, obvious that this mapping, as it only maps state information, can only be part of the conformance considerations to be performed by program-mers.In the case of single concurrent objects, it is tempting to describe how concurrency control in-fluences processing of requests in terms beyond the scope of the object model. Being an intrinsic property of objects, concurrency control may be explained using any model suitable for descri-bing the effects of concurrency control on the execution of requests. If concurrency constraints may be applied to a group of objects this freedom is lost. The semantics established by the un-derlying object system restricts the set of possible models. The key properties are encapsulation of object states and a communicational model of object interaction.5It is obvious that an approach to handling distributed concurrency, which depends on functio-nality not available to ordinary object interaction, is not acceptable. Any such functionality al-lowing concurrency control to violate encapsulation would have disastrous effects on the se-mantics of objects. Functionality allowing influencing of object communication would compli-cate the understanding of object interaction. Thus, influencing concurrent execution within a group of objects has to be based on available object interaction semantics. This leaves two pos-sibilities. Either interpose filter objects into communication paths or make objects explicitly in-teract to perform concurrency control.Interposing communication paths easily fits into the composition-filters model as proposed in [AkBV92]. This approach uses filters specified as part of the interface of an object to interpose and control messages directed to that object. While these filters can easily be used to perform concurrency control in the context of a single object, they are yet too weak to perform concur-rency control on object groups. Concurrency constraints over a group of objects would require interaction among the controlling instances. If these controlling instances are implemented using composition filters, these filters need to be able to cooperate. Consequently a filter would be required to process and consume some of the messages directed to its object and to send mes-sages to other objects involved in a concurrency control relationship. Being part of the object interface, the concurrency control behaviour is tied to the object description. In order to allow reuse of concurrency control descriptions one needs a semantics and mechanisms for reuse of filters. Separating filters from objects will result in definition of filter objects. However, using filter objects for interposing object interaction suffers from naming problems. A client of an ob-ject has to name and address the correct filter object to get to the object actually performing the request.4The cooperative approachIn this section an alternative to realizing concurrency control by interposing object interaction is proposed. It directly follows the concurrency control model presented above. It follows the principle of separation of concerns by encapsulating individual aspects of a behaviour into in-dividual objects.Encapsulation does not restrict an object to performing concurrency control within the bounds of that object. This allows one object to call upon another object to perform concurrency control. By doing this, concurrency control is no longer an intrinsic property of an object. Instead, a be-haviour formerly exhibited by a single object is now represented by the combined behaviour of a group of interacting objects. It is obvious that such a model is applicable to configurations al-ready consisting of a group of interacting objects.Now the world of objects is divided up into two partitions; objects providing arbitrary functional behaviour and objects providing concurrency control needed by the former. But it has yet to be explained how these concurrency control objects can perform their operation. It already has 6been remarked that there is no legal possibility for controlling method execution from outside an object. This, too, has to be initiated from inside that object. However, now all elements of the cooperative approach are available and may be combined to form a homogenous picture.When an object needs a decision from a (concurrency) control object it calls a method from that control object. With this call the object may pass, as parameters, any information needed by the control object to perform the decision. The decisions performed by the control object are actual-ly about whether an executing request within the calling object may proceed or not. Such a deci-sion is performed by delaying an answer to a decision request until the calling executing request may proceed. The object is awaiting this decision either by waiting for the response implicitly, in the case of synchronous communication semantics, or by explicitly requesting an answer in the case of asynchronous communication or wait-by-necessity semantics. When the execution of requests within an object changes state in a way influencing concurrency control, that object may inform an appropriate control object about this state change also using method calls. The combination of all information available to a control object determines the abstract state model available to this control object for performing concurrency control requests.According to the interface control model of concurrency control, starting the execution of a re-quest is the only point to which concurrency control decisions are applicable. However, the more complex a method is the more likely it is for this method to cover sections of different con-currency constraints [Mack84]. This suggests the allowance for method substructures to be made visible at the interface of an object. With this, transitions among these method components also constitute points where concurrency control decisions are required.Introduction of method substructures also suggests a possibility for cleanly integrating the calls to a control object into implementation and into interface description of an object. The sub-structure of a method can be interpreted as a block structure as known from imperative program-ming languages. Upon entry of a block, a call to a control object is performed. Parameters of that call communicate necessary information. The block is entered and execution continues as soon as the call returns. On exit of that block another call to the control object is performed. This is used to inform the control object that execution of this block by the current executing request is being terminated. This also communicates state changes caused by executing this block to the control object.The control object, as it is itself an ordinary object, conforms to a type. This type is mediated by the signature of the methods of that object as observable from an object using this control object. A control object is not part of an ordinary object using it, but gets connected to this or-dinary object at instantiation time of this object.It is easy to employ several control objects from a single object, as there is no distinction bet-ween these control objects and any other object known as far as object interaction is concerned. However, this only works if these different concurrency control objects manage distinct inde-pendent concurrency constraints, not only independent in semantics but independent in compo-nents operated upon. Concurrency constraints intended to be expressed independently require the introduction of an additional level of indirection, a kind of composing control object which implements the composition of the independent constraints.7An example§ 5For simple composition rules it would be possible to integrate composition with the control ob-ject interaction semantics. For example, an AND-operation on constraints would require the more restrictive constraint to be queried first. This occurs with the example of a buffer which is superimposed a request-release-constraint. Execution might only continue after all constraints affected granted access. The example of a privileged reader in a multiple reader/single writer context, who will be granted access even in the presence of active writers, illustrates an OR con-junction, which is required the granting of continuation as soon as the privilege constraint grants continuation. These two examples make it clear that it is better to realize constraint composition using a special object than to try to force it into calling semantics for control objects while loo-sing homogeneity among object interaction semantics.5An exampleFigure 2.1 introduced the FIFO buffer example. The behaviour of such a buffer can be formu-lated using a declarative description based on synchronisation counters as follows: retrieve:N > 0start(retrieve)⇒inc(N)store:N <MAX end(store)⇒dec(N)In this case N denotes a synchronisation counter,MAX denotes the upper bound on the buffer, start(a) and end(a) refer to the start respective termination of the given method, and inc(N)and dec(N) denote increment and decrement of the counter denoted by N.The processing of requests within a FIFO buffer object can be illustrated using the following description in a hypothetical language:8§ 5An example{CNTRL:param class buffer_cntrl type buffer_cntrl_type;// other declarations …retrieve:() fifi-> (…){CNTRL.enter_retrieve(…);// implementation of retrieveCNTRL.leave_retrieve(…);}store:(…) -> (){CNTRL.enter_store(…);// implementation of storeCNTRL.leave_store(…);}}The argument declarations of retrieve and store have been left out for brevity. The argu-ments passed at the calls to CNTRL depend on what information a (control) object of type buf-fer_cntrl_type is expecting. In the case of this simple example, no arguments need being passed at all.Figure 5.1 pictures possible configurations available with cooperative concurrency control to solve the FIFO buffer problem.The“single object” case illustrates the structure, that ordinary objects will exhibit under coo-perative concurrency control. An object (FIFO) implementing functional behaviour (actual buf-fering of items) cooperates with a control object (CNTRL) managing concurrent execution of requests.If the functional behaviour is for some reason distributed among several objects (head and tail), the situation that is labeled distributed buffer - central control is to be encountered. The internal state of the participating functional objects is mapped onto a common abstract state managed by the central control object (CNTRL). Each participating functional object contributes to the com-posite behaviour. It is worth noting, that from the control objects point of view, it does not matter how state and functionality are actually distributed among the functional objects as the central control object still operates on a central view of the composite configuration.In order to efficiently exploit communication properties caused by distribution control objects also have to be split into several parts. This configuration is pictured as distributed buffer -distributed control. It requires special control objects (CNTRL head and CNTRL tail) which use§ 5 An example Arraya suitable distributed concurrency control protocol to implement a distributed view of the ab-stract state of the (distributed) FIFO buffer managed. The functional part of this configuration is identical to the case using central control.This illustrates how cooperative concurrency control allows for independence among imple-mentation of functional and concurrency control behaviour. Changes in the actual implementa-tion of functional behaviour do not cause any changes in the implementation of concurrency control. Functional behaviour need not know anything about the actual realization of concur-rency control.§ 6Conclusions6ConclusionsResearch in inheritance in the context of concurrent objects uncovered the principle of separa-tion of concerns. This paper has presented the concept of cooperative concurrency control. Coo-perative concurrency control separates functional aspects and concurrency control aspects of the behaviour of an object into independent objects. These objects use normal object interaction to achieve the behaviour of the original object via cooperation. Concurrency control objects, en-capsulating concurrency control behaviour, are used by objects realizing functional behaviour. They perform concurrency control decisions. The connection between functional objects and concurrency control objects includes the type of the control object. It is established, for examp-le, by parametrization at instantiation time of a functional object.The cooperative approach is consistent with the notion that an object is responsible for the cor-rect execution of its methods in the context of a concurrent environment. It strictly follows the principle of separation of concerns. As it is based on mechanisms already available with object systems (namely object interaction and parametrization), it is applicable to a variety of current object-based and object-oriented programming languages. Reuse of components (functional ob-jects and concurrency control objects) is available as long as the underlying language does sup-port it.Besides the practical use of cooperative concurrency control, this approach constitutes a base for investigating concurrency control in distributed environments. Declarative approaches on specifying concurrency control can be implemented using cooperative concurrency control. This is due to the flexibility of abstract state specification allowed by modelling abstract state using state information provided with parameters from calls to control object methods. Decla-rative concurrency control specifications, together with a semantics of such specifications, also provide the possibility of deriving from them an actual implementation of a control object. Re-search in this domain could try to integrate declarative concurrency control with framework concepts currently researched and try to describe semantics of concurrency control in terms of cooperative concurrency control.7ReferencesAkBV92M. Aksit, L. Bergmans, S. Vural: “An Object-Oriented Language-Database Integration Model: The Composition-Filters Approach”,ECOOP ‘92 EuropeanConference on Object-Oriented Programming, LNCS 615, 1992BeAk92L. Bergmans, M. Aksit: “Reusability Problems in Object-Oriented Concurrent Programs”,ECOOP 92 Workshop on concurrency,position paper, 1992Caro90 D. Caromel: “Concurrency: An Object-Oriented Approach”,TOOLS 2, pg 183-197, 1990References§ 7Deco89 D. Decouchant, S. Krakowiak, M. Meysembourg, M. Riveill, Rousset de Pina: “A Synchronisation Mechanism for Typed Objects in a Distributed System”,Proc. ofthe ACM SIGPLAN Workshop on Object-Based Concurrent Programming,SIGPLAN, 1989Frøl92S. Frølund, “Inheritance of Synchronisation Constraints in Concurrent Object-Oriented Programming Languages”,ECOOP ‘92 European Conference on Object-Oriented Programming, LNCS 615, 1992Geib92J.-M. Geib, L. Courtrai: “Abstractions for Synchronization to InheritSynchronisation Constraints”,ECOOP ‘92 Workshop on concurrency, positionpaper, 1992Holl92I. Holland: “Specifying reusable components using Contracts”,ECOOP ‘92 European Conference on Object-Oriented Programming, LNCS 615, 1992John91R. Johnson, V. Russo: “Reusing Object-Oriented Design”,University of Illinois, Technical Report UIUCDCS 91-1696, May 1991Neus91 C. Neusius: “Synchronizing Actions”,ECOOP ‘91 European Conference on Object-Oriented Programming, Springer Verlag, 1991Mack84L. Mackert: “Modellierung, Spezifikation und korrekte Realisierung von asynchronen Systemen”, Dissertation, Arbeitsberichte des IMMD, Bd. 16, Nr. 7,1984Mats90S. Matsuoka, K. Wakita, A. Yonezawa: “Analysis of inheritance Anomaly in Concurrent Object-Oriented Languages”,ECOOP/OOPSLA ‘90 Workshop onObjekt-Based Concurrent Systems, Aug 1990McHa91 C. McHale, B. Walsh, S. Baker, A. Donnelly: “Scheduling Predicates”,Trinity College, Dublin, Technical Report TCD-CS-91-24, 1991Shiba91 E. Shibayama: “Reuse of Concurrent Object Descriptions”,Concurrency: Theory, Language and Architecture, LNCS 491, 1991Wegn87P. Wegner: “Dimensions of Object-Based Languages”,Proc. of OOPSLA 1987, SIGPLAN, vol. 22, no. 12, pg. 168-182, 1987。