S. Matsuoka, A. Yonezawa, Analysis of Inheritance anomaly in Object-oriented concurrent programming languages, in: G. Agha, P. Wegner, A. Yonezawa (Eds.), Research Directions in Concurrent Object-Oriented Programming, MIT Press, 1993, pp. 107--150.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....modifiability and extensibility problems are present in many concurrent object oriented programming languages as well. For instance, there is a problem with the inheritance of method implementations in concurrent object oriented programming languages. This problem, termed the inheritance anomaly [15], occurs when implementations of methods of a class cannot be inherited in a subclass due to the differences in synchronization constraints of the class and the subclass. Concurrent classes therefore cannot be extended easily. Similarly, interaction specifications cannot be reused easily. The ....

....composition of a concurrent class by adding and or modifying methods and their interaction behaviors. 4.1 Inheritance anomaly In many concurrent object oriented programming languages there is a problem with the inheritance of method implementations. This problem, termed the inheritance anomaly [15], arises due to the differences in synchronization requirements of a class and its subclasses. We illustrate the problem through the following example: Example 4.1. Inheritance anomaly) Let a concurrent class C define two methods m 1 and m 2 . Implementations of m 1 and m 2 contain, in addition ....

Satoshi Matsuoka and Akinori Yonezawa. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. In Research Directions in Object-Based Concurrency. MIT Press, Cambridge, 1993.

....concurrency re quirements. 2 Related work Various attempts have been done by the object oriented community to separate concurrency issues from functionality. This has been motivated mainly by conflicts between concurrency and inheritance which are identified as the inheritance anomaly problem [10]. Recently, some researchers have proposed aspect oriented programming (AOP) 7] which encompasses the separation of various program aspects (synchronization being only a particular case) into codes written in aspect languages specific for the aspects. The aspect programs are later combined ....

Matsuoka, S. and Yonezawa, A. 1993. Analysis of inheritance anomaly in objectoriented concurrent programming languages. In Research Directions in Concurrent Object-Oriented Programming, chapter 4, pp. 107-150. MIT Press.

....It is well known that inheritance and synchronization constraints in a concurrent object oriented setting often con ict: their simultaneous use tends to require many method rede nitions and to break encapsulation, so that typical practical advantages of object oriented programming are lost. In [18] this phenomenon is studied and is given a name, inheritance anomaly. In MoMi, we do not provide explicit means for concurrency since we think that this is an orthogonal issue and should be dealt with by the underlying concrete language. However, if direct means for synchronization would be added ....

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107-150. MIT Press, 1993.

....same initial state they leave all the objects involved in equivalent nal states. 19 The programmer may state for each object a set of equivalence states with the purpose of de ning state based commutativity and concurrently runnable assertions. Example 3. 3 In a bounded bu er with capacity n [21], all possible combinations of less than n elements make up the equivalence class partial and all combinations (states) with n elements fall in the full class. This treatment of states accommodates both the explicit states assertions and condition de ned states approaches. De nition 3.9 ....

Matsuoka, S., and Yonezawa, A. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages, in G. Agha, P. Wegner, A. Yonezawa, editors, Reserach Directions in Concurrent Object-Oriented Programming, MIT Press, 1993.

....unveiled serious di#culties in merging the two concepts [1, 3] Typically, the code for concurrency control, interwoven in the business code of classes, represented an obstacle to code inheritance, making it essentially impossible even in simple, common situations. The term inheritance anomaly [19] was coined to refer to the issue. Indeed, the problems arising from the interaction of inheritance and concurrency were considered so severe as to suggest removing inheritance from concurrent object oriented languages entirely [1] Commonly, in object oriented code, the set of messages accepted ....

....for instance, method freeze that makes it read only. Whatever the original chunks of code for buffer not . chances are that they must be totally rewritten to take into account the new enabling condition. Generally speaking, the inheritance anomaly has been classified in three broad varieties [19]thatwereviewbelow. Partitioning of states. Inspired by the example above, one may disentangle code and synchronization conditions by describing methods enabling according to a partition of the object s states. To describe the behavior of class Buffer, for instance, the state can be partitioned ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in objectoriented concurrent programming language. In A. Gul, W. Peter, and Y. Akinori, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

....unveiled serious di culties in merging the two concepts [1, 3] Typically, the code for concurrency control, interwoven in the business code of classes, represented an obstacle to code inheritance, making it essentially impossible even in simple, common situations. The term inheritance anomaly [16] was coined to refer to the issue. Indeed, the problems arising from the interaction of inheritance and concurrency were Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for ....

....for instance, method freeze that makes it read only. Whatever the original chunks of code for buffer not . chances are that they must be totally rewritten to take into account the new enabling condition. Generally speaking, the inheritance anomaly has been classi ed in three broad varieties [16] that we review below. Partitioning of states. Inspired by the example above, one may disentangle code and synchronization conditions by describing methods enabling according to a partition of the object s states. To describe the behavior of class Buffer, for instance, the state can be partitioned ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming language. In A. Gul, W. Peter, and Y. Akinori, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107150. MIT Press, 1993.

....object oriented concurrent languages and systems promote intra object concurrency. Several complications arise when ensuring that an object accessed in a concurrent manner is in a consistent state, or that the principles of object orientation are not violated (e.g. inheritance breaks encapsulation [81, 100]) Moreover, for applications that manipulate large data through intensive computations , the fine grain intra object concurrency conflicts with the need of partitioning the data into coarsegrain, manageable sub sets. We propose an inter object concurrency model that exploits data parallelism ....

Satoshi Matsuoka and Akinori Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

....concurrency (multiple threads inside an object) It was found that most OOP concepts (e.g. encapsulation) could be naturally integrated into COOP. However, the integration of inheritance and COOP has not been smooth. One of the main problems with inheritance in COOP is the inheritance anomaly [22,23,24,25]. Inheritance anomaly arises when additional methods of a subclass cause undesirable re definitions of the methods in the superclass. Instead of being able to incrementally add code in a subclass the programmer may be required to re define some inherited code, thus the benefits of inheritance are ....

....1998. Springer Verlag Berlin Heidelberg 1998 572 Lobel Crnogorac et al. in the literature trying to solve the problem, but almost no formal work has been done. For comparison purposes the proposals were usually evaluated on a set of standard examples introduced by Matsuoka and Yonezawa [23]. Such informal approach cannot guarantee that some examples of anomaly are not omitted from consideration. Many proposals claim to have solved the anomaly, however there is a serious lack of agreement due to a large variety of informal definitions used by di#erent researchers, and to the lack of ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Research Directions in COOP, chapter 1, pages 107--150. MIT Press, 1993. 571, 572, 576, 577, 583, 583, 589, 590, 591, 596, 597

....pointed out in the concurrent object orientedlaJ[ z resea) h. NaJ] the reuse of synchroniza(Jx methods by using inherita4) is limited whena method specifiesa set of methodstha ca behaF] z next. This problem iscaFzfi inheritance anomaly,a[ severa mechaJ]zF aa proposed to remedy this problem [20]. Extending the inherita44 mechaJ[4 of scripts in AgenTae to aoJ w extensive script reuseremaJ[ a future work. Acknowledgments TheaeJ(P4 would like totha3 Ta] 3 Shinohax for his contributions in implementing the current version of AgenTanT ....

Matsuoka, S. and Yonezawa, A.: Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages, in Agha, G., Wegner, P., and Yonezawa, A. eds., Research Directions in Concurrent Object-Oriented Programming, pp. 107--150, MIT Press (1993). 6

....ensure that no check has been omitted running the risk of compromising the security of the entire system. Reusability, one of the major bene ts of the object orientation, creates its own set of problems for security. Just as with concurrency which gives rise to the well known inheritance anomaly [4], inheriting code from classes with di erent security policies may create security anomalies. A class that is safe in one context may open a security hole when extended in another context. Of course, from the point of view of the library designer, it is not feasible to design classes that are ....

Matsuoka S, Yonezawa A. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Research Directions in Concurrent Object-Oriented Programming, G. Agha PW, Yonezawa A (eds.). The MIT Press, 1993, chapter 4; 107-150.

....necessary to adjust the selected communication mechanisms whenever the deployment of A and B changes. In the case that communication mechanisms are directly hard coded in components, such adjustments mean modifications of component internals. Analogously with the inheritance anomaly concept [26, 50], we refer to this kind of a post design modification of a component internals enforced by its deployment as deployment anomaly. 30 Figure #0 Modifying component internals during deployment Figure ## Adding a component to reflect change in deployment As an example, consider components A and B ....

Matsuoka, S., Yonezawa, A.: Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. Research Directions in Concurrent Object-Oriented Programming, MIT Press, #993.

....to modularize data abstractions along with operations on them. It further provided mechanisms to group, reuse and extend behavior as well as internal component structure. Recent research has demonstrated that OOP gives rise to certain problematic issues. More specifically, inheritance anomalies [18] emerged from the discussions on conflicts between synchronization and reuse and the need for better separation between synchronization code and the main functionality in concurrent programs. Generalizing on inheritance anomalies, code tangling [16] has given rise to Aspect Oriented Software ....

Matsuoka S., and Yonezawa, A., "Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages ", ed. Agha, G., Wegner, P., and Yonezawa, A., Research Directions in Concurrent Object-Oriented Programming, pp. 107-150, The MIT Press, 1993.

.... in [98] to transform under quite general assumptions synchronous rules of the form (z) into simpler Actor like rules of the form (y) An important problem in concurrent object oriented programming to which rewriting logic has been successfully applied is the so called inheritance anomaly [110], that is, the serious difficulties often encountered when trying to integrate object oriented inheritance and concurrency in a programming language. The paper [117] shows how the inheritance anomaly can be resolved by adopting a declarative programming style with rewrite rules. A more recent ....

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in objectoriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

....not the transitions between states (as opposed to Lotos [4] CSP [10] etc. This is because we suspect that focusing on state allows for a design that exhibits more stability under change. There are some classical problems in concurrent system design (such as the so called inheritance anomaly [13]) where small changes in the design result in small changes in the abstract statespace, but huge changes in the transition system. 6.3 Accessibility An important aspect of every language, construct, or tool is that it is easily accessible to the average software developer. Difficulty to ....

S.Matsuoka and A.Yonezawa.Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. In G. Agha and P. Wegner and A. Yonezawa, Research Directions in Concurrent Object-Oriented Programming, pages 107-150. MIT Press, Cambridge, MA, 1993.

....with very few adaptations. The issues of concurrency and distribution on one side, and the various concepts of the object world such as inheritance, the semantics of method invocations, or encapsulation on the other side create new problems. For instance the so called inheritance anomaly [19] refers to the various limitations that arise in introducing inheritance in a concurrent programming language. This difficulty has been thoroughly studied and several solutions have been proposed [15, 25, 2, 13, 11] Furthermore the non determinism introduced by a distributed environment where ....

....Previous works have shown that synchronization code (i.e. the code defining whether a message can be executed by a concurrent object) can not always be reused without some redefinitions. The purpose of this section is not to give a complete study of the problem (cf. Matsuoka and Yonezawa in [19] for such a work) or to review the numerous proposals, but to show how we deal with this situation in the CAOLAC MOP. In a bounded buffer the synchronization code refers to the entity responsible for prohibiting the execution of a Get message when the buffer is empty, and for prohibiting the ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

....still be made depending on whether synchronization specifications are centralized or not. Such constructs, however, suffer from several characterizing drawbacks; e.g. the inheritance anomaly [8] and the so called code tangling problem [9] Solutions to the former problem have been proposed by [10], 11] and [12] whereas the latter could be faced by adopting an approach that separates synchronization issues from operational issues, according to the proposal of [9] We decided to adopt a synchronization policy that helps avoiding the code tangling problem. To this end, we enforced a clean ....

S. Matsuoka and A. Yonezawa, "Analysis of inheritance anomaly in object-oriented concurrent programming languages", in G.Agha, P. Wegner, and A. Yonezawa, editors, Research directions in Concurrent ObjectOriented Programming, pp. 107-150, 1993.

....and persistence are examples of non functional issues. Combining inheritance with concurrency poses problems in that it is difficult to define classes that make use of concurrency mechanisms and can be then inherited and extended in any meaningful way without exposing implementation details [19] [27]. That one would like to configure these non functional aspects independently from the functional issues can also seen from the fact that objects that function correctly in a sequential environment may fail when exposed to concurrent clients [46] Similarly, one would like to switch persistence ....

Satoshi Matsuoka and Akinori Yonezawa, "Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages," Research Directions in Concurrent Object-Oriented Programming, ed. G. Agha, P. Wegner and A. Yonezawa, MIT Press, Cambridge, Mass., 1993, pp. 107--150. 25. Beyond Objects: Components

....the behavior of a class equipped with a Statechart without the need for modifying directly this Statechart, or (worse ) patching the generated code. For example how can we add an Intelligent Network service to a Plain Old Telephone System This raises questions known as the inheritance anomaly [13], which is present in Uml because of the imperative nature of Statecharts. 3. What does the composition of several dynamic diagrams mean at a modelwise level Can we be less naive than simply using an asynchronous composition semantics, the hell for designers (combinatory explosion of range of ....

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object Oriented Programming. MIT Press, 1993.

....bodies are abstract does not mix well with concurrency. More speci cally, concurrency and class based inheritance are not orthogonal. This well known problem is often referred to as the inheritance anomaly. Unfortunately, inheritance anomaly is not de ned formally, but by means of examples as in [15], where three patterns of inheritance anomaly are given. The examples in [15] demonstrate that extending a base class by new capacities has an impact on the (desirable) concurrent behavior of the capacities that are inherited from the base class. Straightforward extensions to concurrency of ....

....and class based inheritance are not orthogonal. This well known problem is often referred to as the inheritance anomaly. Unfortunately, inheritance anomaly is not de ned formally, but by means of examples as in [15] where three patterns of inheritance anomaly are given. The examples in [15] demonstrate that extending a base class by new capacities has an impact on the (desirable) concurrent behavior of the capacities that are inherited from the base class. Straightforward extensions to concurrency of sequential languages, such as implementing synchronization in method bodies or ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, chapter 4, pages 107-150. The MIT Press, 1993.

....These properties should be preserved by an approach integrating Petri Nets and object oriented concepts. Concepts to resolve inheritance anomalies: Ideally, a notation for the development of concurrent object oriented systems integrates concepts to resolve so called inheritance anomalies [25]. Such anomalies occur if synchronization conditions are integrated into the functional description of a method. Problems arise in this context, as within every subclass containing additional methods the inherited synchronization conditions almost inevitably change. As a consequence, inherited ....

S. Matsuoka and A. Yonezawa. 'Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages'. Research Directions in Concurrent Object-Oriented Programming, MIT Press, 1993.

....have modeled conforms to the real world system, but we do not expect it to be the only way to model it. 7.3 Concurrency and inheritance As we have already said, the deriving (inheritance) of synchronization constraints may clash with encapsulation. This is problem is known as inheritance anomaly [MaYo93]. This phenomenon has been studied already for several years. Solutions for avoiding inheritance anomaly have been presented but none of them have seemed to satisfy the majority of researchers. The basic description of inheritance anomaly can be explained with the situation where synchronization ....

....This situation is in fact very typical in any object oriented implementation languages, like C for instance, where the major concern is reuse and sharing of existing components. It is a notable fact that the occurrence of inheritance anomaly depends on the synchronization scheme of the language [MaYo93]; in other words, redefinitions would be required for classes in an language that adopted a certain synchronization scheme, while the (semantically identical) classes could be safely inherited in another language that provides a different synchronization scheme. Concurrency 45 Another fact is ....

Matsuoka, S., Yonezawa, A., Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. Research Directions in Concurrent Object-Oriented Programming. MIT Press, Cambridge, MA, 1993, pp.107-150.

....executing their methods [6] This paper describes CJava, a concurrent extension to Java featuring concurrent objects. It focuses on the description of the language and its characteristics. A detailed description of the language, with particular attention to the problem of the inheritance anomaly [7], may be found in [8] The paper is organized as follows: Section 2 describes the features provided by Java to support concurrent programming. This will help the reader appreciate how CJava differs from Java and how an implementation of CJava may be provided by means of a preprocessor that ....

....extensive code reuse [8] Most of the existing COOLs force synchronization code to be inherited together with method implementations. This reduces the ability of reusing code because, in most cases, the synchronization code needs to be rewritten in subclasses even if the method bodies would not [7]. The current implementation of CJava is based on a preprocessor that translates CJava programs in Java, together with a small number of classes that implement the CJava run time system. Some of these classes are based on native implementations (i.e. they include native code) As a consequence, ....

S. Matsuoka and A. Yonezawa, Analysis of inheritance anomaly in object-oriented concurrent programming languages. Research directions in Concurrent Object-Oriented Programming, G. Agha, A. Yonezawa, and P. Wegner editors, the MIT Press, 1993.

....stat i c after p r i n t ( thisJoinPoint . methodName ) Figure 1: An example of clash between two aspects 3. Possible clashes between aspect code and specific language mechanisms. One of 3 the best known examples of problems that falls into this category is inheritance anomaly [5]. This term was first used in the area of concurrent object oriented languages [6, 7, 8] to indicate the di#culty of inheriting the code used to implement the synchronization constraints of an application written using one of such languages. In the area of AOP languages, the term can be used to ....

....n i tDone ) System . out . p r i n t l n ( Error : init never called ) Figure 2: An aspect to control the sequence of invocation of di#erent methods All these problems show that AOP is still in its infancy. The experience gained in the area of concurrent object oriented languages [5] suggests that these problems might result more from the linguistic choices made in developing AOLs, rather than from intrinsic limitations of the approach. The problem of finding adequate linguistic features which do not su#er from inheritance anomaly is thus an open research topic. 4 c l ass ....

S. Matsuoka and A. Yonezawa, "Analysis of inheritance anomaly in object-oriented concurrent programming languages," in Research Directions in Concurrent ObjectOriented Programming (G. Agha, P. Wegner, and A. Yonezawa, eds.), pp. 107--150, Cambridge, MA: MIT Press, 1993.

....if each aspect introduces the same method (e.g. method print) with di#erent definitions, they fail when applied together. 3. Possible clashes between aspect code and specific language mechanisms. One of the best known examples of problems that falls into this category is inheritance anomaly [7]. This term was first used aspect CodeOnDemand advise Lou i se ( stat i c after i ng = new I ng r ed i en t s ( ov = new Oven ( advise void Lou i se . act ( stat i c before try book = p . getBook ( Cake c = getCake ( catch ( Except i on e ) ....

....the same operation done when the client server approach is taken) Unfortunately, this is not possible and it was necessary to rewrite the aspect code entirely. All these problems show that AOP is still in its infancy. The experience gained in the area of concurrent object oriented languages [7] suggests that these problems might result more from the linguistic choices made in developing AOLs, rather than from intrinsic limitations of the approach. The problem of finding adequate linguistic features which do not su#er from inheritance anomaly is thus an open research topic. 4 Conclusion ....

S. Matsuoka and A. Yonezawa, "Analysis of inheritance anomaly in object-oriented concurrent programming languages," in Research Directions in Concurrent Object-Oriented Programming (G. Agha, P. Wegner, and A. Yonezawa, eds.), pp. 107--150, Cambridge, MA: MIT Press, 1993.

.... and objects here the distinction is often between the concept of an active object, and where concurrent execution is created by the use of asynchronous method calls, ffl the way in which concurrent activities communicate and synchronise (and yet avoid the so called inheritance anomaly [4]) 3 The Ada 95 Programming Language The Ada 83 language allowed programs to be constructed from several basic building blocks: packages, subprograms, and tasks. Of these, only tasks were considered to be types and integrated with the typing model of the language. Ada 95 extends the facilities ....

....left open) and requeue in the parent is allowed. A consequence of this is that no post processing is allowed after a parent call. 6 Inheritance Anomaly The combination of the object oriented paradigm with mechanisms for concurrent programming may give rise to the so called inheritance anomaly [4]. An inheritance anomaly exists if the synchronization between operations of a class is not local but may depend on the whole set of operations present for the class. When a subclass adds new operations, it may therefore become necessary to change the synchronization defined in the parent class to ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Research Directions in Concurrent ObjectOriented Programming, pages 107--150. MIT Press, 1993.

....implementation is called synchronization code. It is commonly accepted that the synchronization code should be separated from the algorithmic code of an object. The critical point is reconnecting the two separated parts. Some approaches make a static connection, which creates inheritance anomalies [7] 1 . Other approaches introduce special language constructs to allow certain dynamic modifications of this connection in order to avoid certain inheritance anomalies. My approach is to insert a third layer, which is responsible for the reconnection of 1. Matsuoka and Yonezawa evaluated the ....

.... the associated synchronization base class (syncBC) resulting in the synchronization subclass (syncSC) In many synchronization schemes the relationships between algorithmic code in the base class and the synchronization constraints are fixed, which is the reason why inheritance anomalies occur [7]. Even if the code of the base class can be modified, this contradicts the basic object oriented ideas of inheritance. The number of inheritance anomalies is reduced by untying the fixed relations between the base classes. public class RWSync extends Sync protected Object r lck = new Object ....

S. Matsuoka; A. Yonezawa: "Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages". In: G.Agha, A.Yonezawa, and P.Wegner

....If a call was made to A.E, this would be statically defined as a call to T1.E and 118 would be subject to its barrier (E Count 1 and I 0) The barrier would 119 be repeated in the entry body. 120 There is only one queue for each overridden entry. In order to avoid inheri 121 tance anomalies[3]) we propose that all external calls to a protected object are 122 dispatching. This is in conflict with regular tagged types, and to to resolve this, 123 a new pragma could be introduced External Calls Always Dispatch which 124 would apply to regular tagged types. 125 2.4.1 Calling the Parent ....

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object- 441 oriented concurrent programming languages. In Research Directions in Con- 442 current Object-Oriented Programming, pages 107--150. MIT Press, 1993. 443

....end of it) Unfortunately, since they introduce the same method (i.e. the method print) with di#erent definitions, they fail when applied together. Aspect code and specific language mechanisms. One of the best known examples of problems that falls into this category is inheritance anomaly [7]. This term was first used in the area of concurrent object oriented languages [8, 9, 10] to indicate the di#culty of inheriting the code used to implement the synchronisation constraints of an application written using one of such languages. In the area of AOP languages, the term can be used to ....

S. Matsuoka and A. Yonezawa, "Analysis of inheritance anomaly in object-oriented concurrent programming languages," in Research Directions in Concurrent ObjectOriented Programming (G. Agha, P. Wegner, and A. Yonezawa, eds.), pp. 107--150, Cambridge, MA: MIT Press, 1993.

....if the invocation fails (e.g. if the server object becomes unaccessible) the effects of the invocation are canceled. The Karos distributed programming language [27] extends the Argus approach by allowing the association of transactions also to asynchronous invocations. 1em 8 See e.g. [46] for a more detailed description. Migration. In order to improve the accessibility of objects, some languages or systems support mechanisms for object migration. In the Emerald distributed programming language [10] and the COOL generic run time layer [39] the programmer may decide to migrate an ....

....methods, and synchronizations) may conflict with each other, as noted in [49] In some cases, defining a new subclass, even only with one additional method, may force the redefinition of all synchronization specifications. This limitation has been named the inheritance anomaly phenomenon [46]. Specifications along centralized schemes (see Sect. 4.4) turn out to be very difficult to reuse, and often must be completely redefined. Decentralized schemes, being modular by essence, are better suited for selective specialization. However, this fine grained decomposition, down at the level ....

[Article contains additional citation context not shown here]

S. Matsuoka and A. Yonezawa, Analysis of Inheritance Anomaly in ObjectOriented Concurrent Programming Languages, Research Directions in Concurrent Object-Oriented Programming, edited by G. Agha, P. Wegner and A. Yonezawa, MIT Press, 1993, pages 107--150.

No context found.

S. Matsuoka, A. Yonezawa, Analysis of Inheritance anomaly in Object-oriented concurrent programming languages, in: G. Agha, P. Wegner, A. Yonezawa (Eds.), Research Directions in Concurrent Object-Oriented Programming, MIT Press, 1993, pp. 107--150.

No context found.

Satoshi Matsuoka and Akinori Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

Matsuoka, S.; Yonezawa, A.: Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. in Agha, G.; Wegner, P.; Yonezawa, A. (eds.): Research Directions in Concurrent Object-Oriented Programming, MIT Press, 1993

No context found.

S. Matsuoka and A. Yonezawa. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages, pages 107--150. MIT Press, Cambridge, Massachusetts, 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming language. In A. Gul, W. Peter, and Y. Akinori, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

S. Matsuoka and A. Yonezawa, Analysis of Inheritance Anomaly in ObjectOriented Concurrent Programming Languages, in Research Directions in Concurrent ObjectOriented Programming, MIT Press, pp. 107-150, 1993.

No context found.

Satsoshi Matsuoka and Akinori Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Gul Agha, Peter Wegner, and Akinori Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

Satoshi Matsuoka, Akinori Yonezawa, Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages, in: G. Aga, P. Wegner, A. Yonezawa (Eds.), Research Directions in Concurrent Object-Oriented Programming, ACM Press, New York, 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming language. In A. Gul, W. Peter, and Y. Akinori, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in objectoriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, chapter 4, pages 107-150. The MIT Press, 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming language. In Research Directions in Concurrent Object-Oriented Programming, pages 107--150. 1993.

No context found.

S. Matsuoka and A. Yonezawa, "Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages", in Research Directions in Object-Based Concurrency, MIT Press (Cambridge, Mass.), 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

Satoshi Matsuoka and Akinori Yonezawa. Analysis of inheritance anomaly in objectoriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107--150. MIT Press, 1993.

No context found.

S. Matsuoka and A. Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107-- 150. MIT Press, 1993.

No context found.

Satoshi Matsuoka, Akinori Yonezawa, Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages, in: G. Aga, P. Wegner, A. Yonezawa (Eds.), Research Directions in Concurrent Object-Oriented Programming, ACM Press, New York, 1993.

No context found.

Satoshi Matsuoka and Akinori Yonezawa. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Programming Languages. In Research Directions in Object-Based Concurrency. MIT Press, Cambridge, 1993.

No context found.

S.Matsuoka, A.Yonezawa. Analysis of Inheritance Anomaly in Object-Oriented Concurrent Languages. In G. Agha, P. Wegner, and A. Yonezawa, editors, Research Directions in Object -Based Concurrency. MIT Press, 1993.

No context found.

Satoshi Matsuoka and Akinori Yonezawa, Analysis of Inheritance Anomaly in ObjectOriented Concurrent Programming Languages, Research Directions in Object-Based Concurrency, MIT Press, Cambridge (1993).

No context found.

Satoshi Matsuoka and Akinori Yonezawa. Analysis of inheritance anomaly in object-oriented concurrent programming languages. In Gul Agha, Peter Wegner, and Akinori Yonezawa, editors, Research Directions in Concurrent Object-Oriented Programming, pages 107#150. MIT Press Cambridge, Massachusetts, London, England, 1993.

First 50 documents  Next 50

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