Satoshi Matsuoka, Keniro Taura, and Akinori Yonezawa. Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages. In OOPSLA'93, pages 109--126. ACM SIGPLAN, ACM Press, 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....uses of reflection, which extend object functionality by monitoring object accesses at run time, object views focus on restricting object usage to facilitate more efficient data transfer. Object views are more similar to specifications such as enabled method sets [20] and transition specification [15] used in concurrent object oriented languages to express synchronization constraints among methods of the object. Synchronization specifications constrain the order in which object methods can be invoked, but do not provide any guidance on how to improve data transfer costs. Our work focuses on ....

] S. Matsuoka, K. Taura, and A. Yonezawa. Highly efficient and encapsulated re-use of synchroniza-tion code in concurrent object-oriented languages. In Proceedings of OOPSLA '93, Object-Oriented Programming Systems, Languages and Architectures, 1993.

....for inheritance and the term inheritance anomaly, introduced by Matsuoka [MY93] has been widely adopted for referring to related problems. Although, several proposals were presented for overcoming the inheritance anomaly, AGMB91, Ber94, Car90, TS89, Fr92, HSB 96, KL89, KMV 90, McH95, MTY93] to name a few, they have focussed on a particular issue: the specification and reuse of message acceptance constraints. However, earlier research on the design of COOPLs and concurrent programming [Gen81, LH83, Nie87, YSTH87] has identified other issues that have to be addressed in order to ....

....of Server class in figure 3 (left) Inheriting subclasses can extend the synchronization constraints without needing to redefine its methods . 5. Related Work Several approaches have coped with some of the requirements (see 2.2) on the design of synchronization constraints. For example, Fr92, MTY93] cope with composability of synchronization constrains but not with the modularity requirement because synchronization constrains refer to instance variables. DRAGOON[AGMB91] is an example that copes with the latter but not with the former because inheritance between classes specifying ....

Satoshi Matsuoka, Kenjiro Taura, and Akinori Yonezawa. Highly efficient and encapsulated re-use of synchronization code in concurrent objectoriented languages. In Proceedings OOPSLA'93, pages 109--129. ACM, October 1993. Published as SIGPLAN Notices, volume 28, number 10.

....Aspects of Computer Software 91, LNCS 526, p532547, Springer Verlag, 1991. 22] Wegner, P. Concepts and Paradigms of ObjectOriented Programming, ACM OOPS Messenger, Vol.1, No.1, August, 1990. 23] Yi, W. CCS Time = an Interleaving Model for Real Time Systems, Proceedings of ICALP 91, LNCS 510, p217 228, 1991. 24] Yonezawa, A. and Tokoro, M. ed) Object Oriented Concurrent Programming, MIT Press, 1987. Appendix In this appendix we show a sketch of an analysis of a real time program described in R T . We consider a reader writer problem program as shown in Figure 11. This program ....

Matsuoka, S., Taura, K., and Yonezawa, A., Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages Proceedings of ACM OOPSLA'93, p109-126, 1993.

....to specify conditions, and how to modify FIFO message queues to handle messages that do not meet conditions when they reach the head of a message queue. 6. 1 Specifying Conditional Synchronization Techniques for specifying conditional synchronization may be classified into two general categories [MTY93] guards and accept sets. These techniques are used in most concurrent object oriented languages to write the synchronization code necessary to meet the synchronization constraints of concurrent objects. The guard category involves associating a (possibly empty) boolean condition with each method ....

....inheritance anomalies [MWY90] have received much attention by researchers of concurrent object oriented programming languages. They are pernicious enough so that the first versions of the POOL language chose to exclude inheritance entirely because a satisfactory solution could not be found. In [MTY93] the authors identify three general types of inheritance anomalies, which they illustrate with bounded buffer examples that we describe briefly here. The first, state partitioning, can occur when synchronization constraints are specified using explicit message accept sets, like the behaviors in ....

[Article contains additional citation context not shown here]

Satoshi Matsuoka, Kenjiro Taura, and Akinori Yonezawa. Highly efficient and encapsulated re-use of synchronization code in concurrent object-oriented languages. In Proc. OOPLSA '93, pages 109--126. ACM, October 1993. BIBLIOGRAPHY 109

....for this kind of usage, for at least three reasons. First, the combination of independent behavior aspects leads to an extreme increase in the number of states [4] Second, the use of inheritance for state diagrams normally introduces problems which are known under the term inheritance anomaly [8]. Finally, simple state diagrams do not support handling unexpected exceptional situations. For these reasons, the HieraStates formalism is more sophisticated than simple state diagrams. A major influence stems from the domain of reactive systems, and in particular from the STATECHART formalism ....

....of an operation to certain states is called a synchronization constraint. The code needed to implement a synchronization constraint is called synchronization code. It has been pointed out that synchronization code cannot be effectively inherited without non trivial class re definitions [8]. This problem is called inheritance anomaly. This inheritance anomaly has two major reasons. First, in usual concurrent objectoriented languages the synchronization code is intermixed with method implementation code. Second, usual object oriented languages do not support small additions to the ....

[Article contains additional citation context not shown here]

Matsuoka, S., Taura, K., Yonezawa, A.: Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages. In: Paepcke, A. (ed.): Proc. OOPSLA'93, Vol. 28 of SIGPLAN Notices. ACM Press, 1993, pp. 109--126

....without the danger of creating confusion with typical object oriented issues and (3) it is easier to give a formal semantics for this simple language. Object oriented languages are in general more complex and some problems with making such languages concurrent, such as inheritance anomalies [21], are still being discussed. A welldefined semantics is needed in then present context to be able to demonstrate that correctness of real time programs can be established independent of the execution platform. 2 Composability and reusability of real time programs It is generally recognized that ....

....This makes it very difficult to understand the full extent and implications of the various approaches. 15 CONCLUSION 44 14.8 The combination of real time with object orientation With their work the authors of Sina advocate composition filters as a solution to the well known concurrency anomalies [21] in concurrent object oriented languages . They also claim that some inheritance anomalies exist with regard to timing specification that are resolved using real time filters [3, 5] The real time anomalies result in a reduced reusability of code of classes under inheritance. They claim that the ....

S. Matsuoka, K. Taura and Y. Yonezawa, "Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages", in Proceedings OOPSLA '93, Sigplan Notices Vol. 28, No. 10, pp 109-36, 1993.

....object oriented programming. There is significant research into extending C for concurrent execution (for example [Kal 93, Ungerer 93] A particular issue that has received much attention is the problem of inheriting methods and synchronisation specifications [Ferenczi 95, Gehani 93, Matsuoka 93] Other sequential object oriented languages that have also been extended for concurrent execution include Smalltalk [Yaoqing 93] and Eiffel [Jzquel 93, Meyer 93] Languages that have been specifically designed for concurrent object oriented programming include Guide [Krakowiak 90] Orca [Bal ....

S. Matsuoka, K. Taura & A. Yonezawa, "Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages", Proc. of the Conf. on Object-Oriented Programming, Systems, Languages and Applications, 26 September - 1 October 1993, Washington, DC, pp. 109-126.

.... is full( Returns TRUE if buffer is full bool is empty( Returns TRUE if buffer is empty constraints: disable put when (count = dim) disable delete, head when (count = 0) The choice of a concrete synchronization constraint has an influence in the so called inheritance anomaly [MTY93][Fr 92] However, we do not address this problem here and assume a simple guard mechanism that allows us to disable operations. This mechanism is a simplified version of the one defined in [Fr 92] Objects are active entities that react in response to operation invocations. An object can be in one ....

Matsuoka, S., Taura, K., Yonezawa, A.: "Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages". OOPSLA'93.

.... : workerMethod , args : data1, replyTo : r1 ) self.aSend( target : self.worker2, key : workerMethod , args : data2, replyTo : r2 ) self.waitAllEvents( r1.atState( Ready , r2.atState( Ready , return self.combineResults(r1.getResult( r2.getResult( 2222 duced by Matsuoka[26], we show in 4.3.1 how the features in our model provide support for reusing synchronization constraints on method invocation requests. Then, in 4.3.2 we show how the features of our model can be used to specify active object behaviors that can be combined and reused though class inheritance. ....

....Thus, the activation condition will constrain the execution of all methods of the classes that inherit the lock mixin. The specification of constraints on set of methods that be extended by methods defined in subclasses is inspired by similar previous proposals from Kafura and Lee[18] and Matsuoka[26]. 4.3.2 Combining Behavioral Patterns through Inheritance Previous proposal for combining concurrency features with class inheritance considered that, in order to be able to reuse methods in subclasses through inheritance, methods should not contain any synchronization code. As we discussed in ....

[Article contains additional citation context not shown here]

Satoshi Matsuoka, Kenjiro Taura and Akinori Yonezawa,"Highly Efficient and Encapsulated Re-use of Synchronisation Code in Concurrent Object-Oriented Languages," Proceedings OOPSLA'93,ACMSIGPLAN Notices, vol. 28, no. 10, Oct. 1993, pp. 109--129

....and Method Declaration: Classes serve as templates from which instance objects can be created. 1 RT does not provide inheritance mechanism. This is because inheritance in concurrent object oriented languages often causes unexpectable synchronization time, called inheritance anomaly (see, e.g. [10]) We need further investigation about inheritance mechanism for concurrent object oriented languages with time constraints. All objects in the same class contain the same structure: internal data and methods. A class declaration defines the class name, its instance variables, its initial ....

Matsuoka, S., Taura, K., and Yonezawa, A., Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages Proceedings of ACM OOPSLA'93, p109-126, 1993.

....specifications (on scheduling of message acceptance) turns out not to always work smoothly. This problem has recently been coined as inheritance anomaly. Finding the most expressive, generic and reusable synchronization scheme is currently an active field of research. Recent results (see [MTY93] for a very good study and proposal) show that synchronization specifications need to be: abstract enough, apart from method definitions, among various synchronization schemes proposed (because there is (currently) no single synchronization scheme which is a silver bullet) and, last but not the ....

S. Matsuoka, K. Taura, and A. Yonezawa. Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages. Proceedings of OOPSLA'93, Special Issue of Sigplan Notices, Vol. 28, No 9, September 1993.

....A fourth way could be reusing and inheriting the concurrency control code from the initial class to obtain a behaviour for an object which can be involved in a conversation. Re use and inheritance of the concurrency control code are themselves an extremely important topic of research in COOLs [8]) 4.3. Conversation object We proposed the concept of the conversation of objects. The next reasonable step is to consider the conversation as an object (a kind of resource used by all explicit conversation participants) This way seems the most object oriented; it allows to facilitate the ....

Matsuoka, S., Taura, K. and Yonezawa, A. Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent ObjectOriented Languages. In Proceedings of the OOPSLA'93 109-126; 1993.

.... We are going to consider a different set of COOLs, in which active concurrency is represented by an asynchronous method call or by activating the object body after the object creation, and passive concurrency has the form of synchronization constraints (Eiffel [6] ACT [7] POOL [8] ABCL [9]; Arche [10] Ada9X, the protected type and the barrier conditions [3] These features are intended for controlling synchronization between objects; to do this, the set of messages an object can receive is made changeable by the object programmer. As an example of the latter, we can consider view ....

....problem concerning state inconsistency in our first scheme. A similar problem arises here because some method of the explicit participant can be called while it is in the conversation. Certain features of COOLs allow the solution of this problem in the following way. Let us consider the proposals [9] concerning re using and inheriting the synchronization code in COOLs. This is an extremely important research topic for developing COOLs themselves because, generally speaking, adding new methods in a subclass can cause the re writing of the entire synchronization code and, if this code is ....

[Article contains additional citation context not shown here]

Matsuoka, S., Taura, K. and Yonezawa, A. Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages. In Proceedings of the OOPSLA'93 109-126; 1993.

....G good B blown queries r getResistance( Ohms commands p consume(p:Pulse) We now specify the dynamic availability of methods using a finite state machine. As we discuss in Section 7, this is closely related to the use of guards or enabled sets in synchronization code for concurrent objects [22, 23, 40]. An important difference is that these techniques tend to partition the methods dynamically, according to the values of boolean expressions involving instance variables. Instead, we simply partition the methods according to the logical states we have defined, and allow individual implementations ....

.... strategies have also been proposed for coding such classes [9, 13] Some authors have addressed the particular challenges of inheriting the state machine implementation code [15, 38] a problem remarkably similar to the so called inheritance anomaly in concurrent object oriented languages [22, 23]. The second thread arises directly from issues in object oriented concurrency. Nierstrasz s regular types [27] use logical finite state machines (or regular expressions) as the basis for an extended notion of types for active objects. Starting with distributed objects in the spirit of actors [2] ....

Satoshi Matsuoka, Kenjiro Taura, and Akinori Yonezawa. Highly efficient and encapsulated re-use of synchronization code in concurrent object-oriented languages. In Paepcke

....of the language, called ABCL 1, like the underlying actor model, did not support any form of inheritance, and is therefore an objectbased language. However, when adding inheritance to the language, the concept of inheritance anomaly is introduced into object oriented concurrent programming, [97, 98, 99, 100]. Inheritance anomaly is classified into three major categories: 1) Partioning of acceptable states (State Partitioning Anomaly) 2) History only sensitiveness of acceptable states (History only Sensitiveness Anomaly) and (3) Modification of acceptable states (State Modification Anomaly) It was ....

....such that they can be inherited, overridden, or extended separately without affecting each other. Furthermore, one scheme can be integrated and composed with other schemes. These standard protocols are provided to support synchronization schemes for resolving the inheritance anomaly [97, 98, 99, 100]. In AKL , each method is executed in the context of a class, called base class . This class may not be the class where the method is defined. The current contextual class is used to determine dynamically which methods are called. Within a method, the base class is referred to by the reserved ....

[Article contains additional citation context not shown here]

Matsuoka S., Taura K., Yonezawa A., Highly Efficient and Encapsulated Reuse of Synchronization Code in Concurrent Object-Oriented Languages, OOPSLA, Proceeding, 1993.

....interpretation of abstract states is more restrictive than ours in that objects have to be in exactly one abstract state at a time. Our more flexible approach in defining abstract states avoids a number of problems related to the use of class inheritance which are known as inheritance anomalies [16].The coordination of multiple active objects developed independently has been addressed by other research; Synchronizers [9] and Abstract Communication Types (ACTs) 2] are two relevant proposals. An essential difference of these proposals from our work is that they both use method invocations, ....

S. Matsuoka, K. Taura and A. Yonezawa,"Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages," Proc. OOPSLA'93, ACM, SIGPLAN Notices, vol. 28, no. 10, pp. 109-129, October

....in the size of executable files but no per object space or time overhead. 8.7.4 Related Work It seems that very few designers of synchronisation mechanisms provide details of the run time overhead of synchronisation in papers that they write. One notable exception is Matsuoka et al. Mat93] MTY93] TM93] who provide details of the run time overhead of synchronisation in their implementation of the ABCL language on a massively parallel computer. ABCL supports concurrency between objects but not within an object. This simplifies their task of implementation somewhat, but even so they have ....

....in the expressive power they possessed, but Matsuoka did not comprehend this. He therefore proposed that a language support several synchronisation mechanisms, reasoning there was a good chance that, between them all, these mechanisms might avoid most all categories of the inheritance anomaly [MTY93, pg. 113] For example, if the use of a particular mechanism to implement the synchronisation policy for a base class resulted in subclasses suffering a particular category of inheritance anomaly then a programmer could re implement the synchronisation code of the base class in a different ....

Satoshi Matsuoka, Kenjiro Taura, and Akinori Yonezawa. Highly Efficient and Encapsulated Re-use of Synchronisation Code in Concurrent Object-Oriented Languages. In Proceedings of OOPSLA'93, pages 109--126, October 1993. Published as a special issue of SIGPLAN Notices, 28(10).

....and product of state sets. This is described in detail by Teege (1994) An example is depicted in Figure 5. The refinement of the states unstarted and finished into substates is done separately. If the two schemes in the lower part of the figure are combined the diagram of Figure 4 results. Matsuoka et al. 1993) have pointed out, that the use of diagram based approaches for supporting state dependent behavior at run time inherently conflicts with the use of inheritance. They call this effect inheritance anomaly . However, the reason for this anomaly is the lack of fine grained modifications of inherited ....

Matsuoka, S., Taura, K. and Yonezawa, A.: 1993, Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages, in A. Paepcke (ed.), Proc.

....of AtBuf. Xi In this example, class TwoBufs is used to compose two instances of abstraction AtBuf along with additional synchronization constraint. However, such a composition requires changes in the abstraction (AtBuf) Inheritance anomaly: The second problem, termed the inheritance anomaly [16], arises due to the diverse synchronization requirements of a class and its subclasses. Example 2.3. Inheritance anomaly) Let class NBuf extend class AtBuf by defining a new method GetLst. Method GetLst interacts with Read and Write of AtBuf. This implies that synchronization properties of ....

....Work In most approaches to concurrent programming, implementations of computations and synchronization are embedded within the implementation of components. Separation of implementation of computational and interaction behaviors has been proposed for the resolution of the inheritance anomaly [16]. However, focus here has mostly been on resolving a specific instance of the program composition anomaly. It has not been studied within the general context of concurrent program composition. Svend and Agha [10] also use the notion of separation of implementations of object and coordination ....

Satoshi Matsuoka, Keniro Taura, and Akinori Yonezawa. Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages. In OOPSLA'93, pages 109--126. ACM SIGPLAN, ACM Press, 1993.

.... synchronization code and its reuse by inheritance [12, 15, 10] and (b) the first classing of synchronization code elements [5, 11] Recently the use of multiple synchronization schemes in the same language was advocated, allowing the programmer to choose the most appropriate scheme for each case [9, 8]. CA C follows these ideas and provides two distinct synchronization mechanisms, thereby regulating both internal and external concurrency. In CA C method invocations on any object can be specified on the client code as synchronous or asynchronous. In synchronous calls the client thread ....

....as related approaches because threads exist only within an object. Concurrency annotations are specified by a small amount of code and require less knowledge about the inherited synchronization code (annotations) than the approaches based on named sets of methods such as those present in ABCL R2 [9, 8] and some Actor languages [5, 16] It contemplates synchronization schemes for both internal and external concurrency, raising a new class Stack protected: private stuff public: void push( void pop( client code . Stack a, pa= a; a.push( pa pop( Figure 1: Stack class ....

[Article contains additional citation context not shown here]

Satoshi Matsuoka, Kenjiro Taura, and Akinori Yonezawa. Highly efficient and encapsulated re-use of synchronization code in concurrent object-oriented languages. In OOSPLA '93 Proceedings, ACM SIGPLAN Notices, volume 28, pages 109--126. n, October 1993.

....the required mechanism needed for object encapsulation and representation and acts as the basis for modelling various forms of inheritance. In general, there are a number of ways to achieve encapsulation (and hence inheritance) either in a (concurrent) logic ( 6,13,27,28] or a functional ([4,17,18,31]) framework. Here we concentrate on those techniques that use records as first class objects. Object Oriented Term Graph Rewriting George A. Papadopoulos 18 We use as an example the unavoidable 2 and 3 dimensional point with a number of elementary methods associated with it. A first ....

....and its value can even be changed. It has recently been shown ( 18] that this approach can lead to an elegant solution to the so called inheritance Object Oriented Term Graph Rewriting George A. Papadopoulos 23 anomaly caused by the conflicting nature of concurrency and inheritance ([17,18,31]) In particular, the problem arises because of the need in a concurrent OOP environment to include in the code for the methods of an object some synchronisation constraints on the acceptance of a message by an object. A typical example is that of a bounded buffer where a put message should be ....

[Article contains additional citation context not shown here]

Matsuoka S., Taura K. and Yonezawa A., Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages, Proceedings 8th OOPSLA'93, Washington D. C., USA, Sept. 26-28, ACM Computer Society Press, 1993, p. 109-126. Object-Oriented Term Graph Rewriting George A. Papadopoulos --- 34 ---

....constraints are specified separately from the code of methods. As methods do not contain any synchronization code, it is easier to reuse them in subclasses without modification. Various approaches for specifying, inheriting and combining inherited synchronization constraints have been proposed [11, 12, 13, 14, 15, 16, 17, 18, 19, 20]. 2.1.3 Object Coordination In a concurrent object oriented program coordination between cooperating objects is traditionally expressed through the use of concurrency constructs embedded in the implementation of the objects. The main motivation behind the work on object coordination is to allow ....

S. Matsuoka, K. Taura, and A. Yonezawa, "Highly efficient and encapsulated re-use of synchronisation code in concurrent object-oriented languages," in Proceedings OOPSLA'93, vol. 28(10) of ACM SIGPLAN Notices, pp. 109--129, October 1993.

....involves first class operations on enable sets each time a message is received. Although the cost of such operations on Rosette could be kept relatively low for coarse grained concurrency, it is nevertheless unavoidable, and could incur substantial overhead in fine grain parallel computing (see [73] for discussions) Despite its limitations, we do acknowledge the significance of Rosette in pointing out that some first classing of elements of synchronization scheme provides the possibility of enlarging the class of synchronization code that can be safely inherited. In Chapter 6, we will ....

....management among the objects. Nevertheless, the idea of making the synchronization scheme implicit, was valuable. 6. 3 Our New Proposal We have recently proposed a set of language OOCP languages primitives that provide high degree of efficient and encapsulated re use of synchronization code[73]. The primitives are being incorporated into the new version of ABCL we are currently designing implementing. The proposal is designed with high practicality in mind it extends and extensively refines the ideas in the past proposals to (1) separate and localize the synchronization schemes from ....

Satoshi Matsuoka and Akinori Yonezawa. Highly efficient and encapsulated re-use of synchronization code in concurrent object-oriented languages. (Submitted), 1993.

No context found.

Satoshi Matsuoka, Keniro Taura, and Akinori Yonezawa. Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages. In OOPSLA'93, pages 109--126. ACM SIGPLAN, ACM Press, 1993.

No context found.

Satoshi Matsuoka, Keniro Taura, and Akinori Yonezawa, Highly Efficient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages, OOPSLA'93, ACM SIGPLAN, ACM Press, pp. 109#126 (1993).

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC