Interner Bericht. Institut für Mathematische Maschinen und Datenverarbeitung der Friedrich-Alexander-Universität Erlangen-Nürnberg

Transcription

1 Cooperative Concurency Control Rainer Pruy November 1992 TR-I Interner Bericht Institut für Mathematische Maschinen und Datenverarbeitung der Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl für Informatik IV (Betriebssysteme)

2

3 Cooperative Concurrency Control Rainer Pruy University Erlangen-Nürnberg Institut für mathematische Maschinen und Datenverarbeitung IV Lehrstuhl für Betriebssysteme Martensstraße 1 D-W-8520 Erlangen Germany phone: fax: pruy@informatik.uni-erlangen.de Abstract Today research on concurrency in object systems concentrates on concurrent objects. If one has to address situations involving concurrency control conditions spanning several objects one is still on one s own. This paper illustrates the need to be able to describe concurrency control in distributed situations. It presents the concept of cooperative concurrency control as a first step in addressing this problem. Cooperative concurrency control separates functional behaviour and concurrency control into individual objects interacting to achieve the behaviour of a single concurrent object. As this approach is based on object interaction it naturally extends to distributed situations. Keywords concurrency, distribution, object interaction, cooperation, composition 1

4 1 Introduction Experience 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 independence 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 behaviour 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 results can be summarized by the following two requirements for object interface descriptions: separation of concerns The different aspects of the behaviour of an object should be specified using separate descriptions allowing for independent modifications of these descriptions. In the presence of concurrency there are at least two such aspects, namely functional behaviour and dynamic behaviour. If there are independent aspects of dynamic behaviour even these should be expressed using separate descriptions. The overall behaviour of an object results from a combination of all behavioural aspects. Incremental modification of individual aspects requires clean interfaces between the separate descriptions. flexible modelling of an object-state needed for concurrency control Encapsulation prevents concurrency constraints from referring to state information internal to the object. Thus, needed state information has to be modelled at the interface level. The limitations of the underlying principles used in this modelling process 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

5 2 Concurrency in distributed environments currency and the solutions available with current object systems. A model for concurrency control will be presented in section 3. Based on this model an implementation strategy is developed, which is outlined in section 4. 2 Concurrency in distributed environments Objects 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 concurrency only in the (local) context of individual objects ignores the need for controlling concurrent execution under constraints spanning several objects. A standard answer to this problem is delegating responsibility to alternate concepts. Usually transaction concepts are mentioned. However, transactions are not well suited for handling general 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 internal 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 location 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 unavoidable in many cases for the pure functional behaviour, as the notion of locality is different 3

6 A model for concurrency control 3 retrieve store FIFO fifo_head fifo_tail Abb. 2.1 Example: FIFO buffer between 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 depend 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 captured 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 single object but also in the case of describing concurrent behaviour of object structures. 3 A model for concurrency control Now, that the problem has been outlined, it is necessary to look at how concurrency control operates. 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. 4

7 3 A model for concurrency control abstract state directs concurrency control environment enters encapsulation border controls determines internal state manipulate requests Abb. 3.1 model of concurrency control In 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 knowledge of the initial state and monitoring requests of an object. Such monitoring, though, is inaccurate due to indeterminism resulting from concurrent execution of requests. As long as such indeterminism 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 environment. 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 programmers. In the case of single concurrent objects, it is tempting to describe how concurrency control influences 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 describing 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 underlying object system restricts the set of possible models. The key properties are encapsulation of object states and a communicational model of object interaction. 5

8 The cooperative approach 4 It is obvious that an approach to handling distributed concurrency, which depends on functionality not available to ordinary object interaction, is not acceptable. Any such functionality allowing concurrency control to violate encapsulation would have disastrous effects on the semantics of objects. Functionality allowing influencing of object communication would complicate 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 possibilities. Either interpose filter objects into communication paths or make objects explicitly interact 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 concurrency 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 messages 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 object has to name and address the correct filter object to get to the object actually performing the request. 4 The cooperative approach In 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 individual 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 behaviour 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 already 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 6

9 4 The cooperative approach been 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 actually about whether an executing request within the calling object may proceed or not. Such a decision 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 request 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 concurrency 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 substructure of a method can be interpreted as a block structure as known from imperative programming 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 ordinary object at instantiation time of this object. It is easy to employ several control objects from a single object, as there is no distinction between 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 independent concurrency constraints, not only independent in semantics but independent in components 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. 7

10 An example 5 For simple composition rules it would be possible to integrate composition with the control object 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 conjunction, 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 loosing homogeneity among object interaction semantics. 5 An example Figure 2.1 introduced the FIFO buffer example. The behaviour of such a buffer can be formulated using a declarative description based on synchronisation counters as follows: retrieve: N > 0 start(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

11 5 An example FIFO: class type FIFO_type { CNTRL: param class buffer_cntrl type buffer_cntrl_type; // other declarations retrieve: () fifi-> ( ) { CNTRL.enter_retrieve( ); // implementation of retrieve CNTRL.leave_retrieve( ); } } store: ( ) -> () { CNTRL.enter_store( ); // implementation of store CNTRL.leave_store( ); } The argument declarations of retrieve and store have been left out for brevity. The arguments passed at the calls to CNTRL depend on what information a (control) object of type buffer_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 cooperative concurrency control. An object (FIFO) implementing functional behaviour (actual buffering 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 composite 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 9

12 An example 5 FIFO CNTRL Single object case head tail CNTRL Distributed buffer - central control head tail CNTRL head CNTRL tail Distributed buffer - distributed control Abb. 5.1 cooperative concurrency control configurations a suitable distributed concurrency control protocol to implement a distributed view of the abstract 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 implementation of functional and concurrency control behaviour. Changes in the actual implementation 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 concurrency control. 10

13 6 Conclusions 6 Conclusions Research in inheritance in the context of concurrent objects uncovered the principle of separation of concerns. This paper has presented the concept of cooperative concurrency control. Cooperative 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, encapsulating 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 example, by parametrization at instantiation time of a functional object. The cooperative approach is consistent with the notion that an object is responsible for the correct 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 objects and concurrency control objects) is available as long as the underlying language does support 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. Declarative 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. Research 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. 7 References AkBV92 BeAk92 M. Aksit, L. Bergmans, S. Vural: An Object-Oriented Language-Database Integration Model: The Composition-Filters Approach, ECOOP 92 European Conference on Object-Oriented Programming, LNCS 615, 1992 L. Bergmans, M. Aksit: Reusability Problems in Object-Oriented Concurrent Programs, ECOOP 92 Workshop on concurrency, position paper, 1992 Caro90 D. Caromel: Concurrency: An Object-Oriented Approach, TOOLS 2, pg ,

14 References 7 Deco89 D. Decouchant, S. Krakowiak, M. Meysembourg, M. Riveill, Rousset de Pina: A Synchronisation Mechanism for Typed Objects in a Distributed System, Proc. of the ACM SIGPLAN Workshop on Object-Based Concurrent Programming, SIGPLAN, 1989 Frøl92 Geib92 S. Frølund, Inheritance of Synchronisation Constraints in Concurrent Object- Oriented Programming Languages, ECOOP 92 European Conference on Object- Oriented Programming, LNCS 615, 1992 J.-M. Geib, L. Courtrai: Abstractions for Synchronization to Inherit Synchronisation Constraints, ECOOP 92 Workshop on concurrency, position paper, 1992 Holl92 I. Holland: Specifying reusable components using Contracts, ECOOP 92 European Conference on Object-Oriented Programming, LNCS 615, 1992 John91 Neus91 Mack84 Mats90 McHa91 Shiba91 R. Johnson, V. Russo: Reusing Object-Oriented Design, University of Illinois, Technical Report UIUCDCS , May 1991 C. Neusius: Synchronizing Actions, ECOOP 91 European Conference on Object-Oriented Programming, Springer Verlag, 1991 L. Mackert: Modellierung, Spezifikation und korrekte Realisierung von asynchronen Systemen, Dissertation, Arbeitsberichte des IMMD, Bd. 16, Nr. 7, 1984 S. Matsuoka, K. Wakita, A. Yonezawa: Analysis of inheritance Anomaly in Concurrent Object-Oriented Languages, ECOOP/OOPSLA 90 Workshop on Objekt-Based Concurrent Systems, Aug 1990 C. McHale, B. Walsh, S. Baker, A. Donnelly: Scheduling Predicates, Trinity College, Dublin, Technical Report TCD-CS-91-24, 1991 E. Shibayama: Reuse of Concurrent Object Descriptions, Concurrency: Theory, Language and Architecture, LNCS 491, 1991 Wegn87 P. Wegner: Dimensions of Object-Based Languages, Proc. of OOPSLA 1987, SIGPLAN, vol. 22, no. 12, pg ,