J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent OOP. In European Conference on Object-Oriented Programming (ECOOP'87), volume 276 of Lecture Notes in Computer Science, pages 32--40. Springer-Verlag, 1987.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....are decoupled: specified separately by the programmer these are then weaved together by the Jeeg compiler. 1 Introduction In the late eighties, the first experiments in mixing object oriented programming languages and concurrency 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 ....

J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent OOP. In European Conference on Object-Oriented Programming (ECOOP'87), volume 276 of Lecture Notes in Computer Science, pages 32--40. Springer-Verlag, 1987.

....Concurrent Programming General Terms Languages, Design Keywords Java, Inheritance Anomaly, Temporal Logic 1. INTRODUCTION In the late eighties, the rst experiments in mixing object oriented programming languages and concurrency 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 ....

J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent OOP. In European Conference on Object-Oriented Programming (ECOOP'87), volume 276 of Lecture Notes in Computer Science, pages 3240. Springer-Verlag, 1987.

....primitives[6] found in Java may be theoretically sufficient for expressing synchronization, implementing complex synchronization specifications using such low level tools is definitely cumbersome and error prone. Moreover, such architectures do not scale well and have some reuse problems[7]. Such an architecture also assumes a shared memory of some kind, which does not fit well in a system that needs to address distribution as well. 1.3. Reuse of sequential code Reuse of sequential code does not here mean reusing legacy applications in order to build concurrent and distributed ....

Jean-Pierre Briot and Akinori Yonezawa, 'Inheritance and synchronization in concurrent OOP', in European Conference on Object-Oriented Programming (ECOOP'87), Springer-Verlag, LNCS 276, 1987, pp. 3240.

....research issues which, we believe, are essential for achieving effective reuse of concurrent software. 1. Introduction ThepeW LIIW for interference between concurrency constructs and object oriented mechanisms suphanism reuse has been noted recently by a number ofindep W) I researchers [8], 17] 29] 32] Whereas one might (naively)expve issues of concurrency to be orthogonal to those of encap 4UL W) and reuse, it turns out that objects whoseimpW:4:L4W) make use of concurrency constructs are less likely to be extendible or reusable within new contexts without considerable ....

J-P. Briot and A. Yonezawa, "Inheritance and Synchronization in Concurrent OOP," Proceedings of the EuropW ? Conference on Object-oriented Programming,pr 35-43, Paris, France, June 15-17, 1987.

....approaches to solve this problem have been proposed as well. Finally, communication protocols can have additional constraints which the conventional object model and composition techniques cannot adequately cope with, like for example distributed, realtime and synchronization constraints [4] 5] [7] . In order to solve the compositional modeling problems we can identify two research approaches. The first approach takes the object models and tries according to some specific problem to find solutions. Subsequently, the object model is then adjusted for these specific situations. We adopt the ....

. J-P. Briot and A. Yonezawa. Inheritance and Synchronization in Concurrent OOP, Proc of the ECOOP'87 Conference, Springer-Verlag, 1987, pp. 32-40.

....in writing concurrent programs is the specification of synchronization code. It is therefore most desirable to avoid re writing of such code and to exploit inheritance for code reuse. The conflict between inheritance and synchronization mechanisms has been reported by many researchers [7, 13, 17, 26, 32, 33, 34, 41, 43]. Tomlinson and Singh [41] define a synchronization mechanism as interfering with inheritance if local changes in the inheritance hierarchy (for example, adding a new method to a subclass) require changes in the synchronization constraints elsewhere in the hierarchy. Because of this interference, ....

J.P. Briot and A. Yonezawa, Inheritance and Synchronization in Concurrent OOP, ECOOP'87, 32-40.

....services, the synchronization cannot easily be reused by inheritance. For instance, each time a new exported routine is added to a subclass, the control has to be completely redefined because the corresponding requests need to be explicitly served. Several articles have identified this problem [BY87, Ame87, DKM 89, Pap89, TS89, KL90] On the contrary, the declarative nature of a implicit control promotes and facilitates synchronization reuse. If a new routine is added, we night just have to specify its synchronization conditions, and reuse the old one for inherited routines. 2.5 Some ....

J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent oop. In European Conference on Object-Oriented Programming, June 1987.

....object should be allowed to execute. The conflictual nature of methods depends on the semantics a programmer wants to give to the object he is designing, so that the language should provide him a way to describe acceptance and rejection of a method request. As noted by many previous research like [3, 14, 8, 11], the simultaneous use of synchronization mechanisms and the re use paradigm of object oriented languages lead to conflicts. This phenomenon is called inheritance anomaly in the literatture [3] Let O 1 be an object providing two methods m and m 0 and let O 2 extend O 1 with a new method m ....

....describe acceptance and rejection of a method request. As noted by many previous research like [3, 14, 8, 11] the simultaneous use of synchronization mechanisms and the re use paradigm of object oriented languages lead to conflicts. This phenomenon is called inheritance anomaly in the literatture [3]. Let O 1 be an object providing two methods m and m 0 and let O 2 extend O 1 with a new method m 00 . When O 1 is designed, the methods m and m 0 are given a synchronization policy (from mutual exclusion to full concurrency) But in O 2 , how do those inherited methods synchronize with m ....

J.P. Briot and A. Yonezawa. Inheritance and Synchronization in Concurrent Object-Oriented Programming. In Proceedings of the European Conference on Object Oriented Programming (ECOOP'87), special Issue of Bigre No. 54, pages 35--43, Paris, 1987.

....open research issues which, we believe, are essential for achieving effective reuse of concurrent software. 1. Introduction The potential for interference between concurrency constructs and object oriented mechanisms supporting reuse has been noted recently by a number of independent researchers [8], 17] 29] 32] Whereas one might (naively) expect issues of concurrency to be orthogonal to those of encapsulation and reuse, it turns out that objects whose implementations make use of concurrency constructs are less likely to be extendible or reusable within new contexts without ....

J-P. Briot and A. Yonezawa, "Inheritance and Synchronization in Concurrent OOP," Proceedings of the European Conference on Object-oriented Programming, pp. 35-43, Paris, France, June 15-17, 1987. M. Papathomas and O. Nierstrasz 203

....message passing objects, and passive, lockable objects have been proposed and implemented. Unfortunately none of these approaches has yet succeeded in resolving basic conflicts between concurrency mechanisms and the encapsulation that is needed for the safe use and reuse of object oriented code [6], 14] 26] 27] 28] We claim that the difficulty of the language design problem is due largely to the lack of: widely accepted and well understood models of concurrency . good tools for prototyping languages . a good understanding of reuse criteria for encapsulated software We propose a ....

....5. Viewing Types as Partial Specifications of Behaviour The key problem in designing a concurrency model consistent with the principles of object oriented programming is how to package concurrent objects so that instantiation and inheritance can be safely applied without violating encapsulation [6], 14] 26] 28] Signatures provide an O. Nierstrasz, M. Papathomas 8 abstract view of objects hiding implementation details, and thus furnish useful notions of substitutability, subtyping and type checking. Unfortunately signatures fail to provide enough information about the externally ....

J-P. Briot and A. Yonezawa, "Inheritance and Synchronization in Concurrent OOP," Proceedings of the European Conference on Object-oriented Programming, pp. 35-43, Paris, France, June 15-17, 1987.

....of the synchronization mechanisms of Guide with inheritance. Kafura and Lee [KL88] examine more generally the problem of integrating inheritance in COOPLs. They compare and classify the approaches taken by various languages and propose their solution for the language ACT . Briot and Yonezawa [BY87] discuss inheritance for COOPLs assuming no shared memory. They take the approach to support inheritance by delegation [Lie86] and show that the messages used for delegation heavily interfere with normal processing causing difficult synchronization problems. In the following we will discuss the ....

....method getrear. 6.1 Discussion First there are languages that by their construction are not suitable for supporting class inheritance. These are languages like SR, Emerald and ABCL 1. For such languages delegation seems a reasonable alternative for code sharing, but it is not without problems [BY87]. In languages like Trellis Owl and Hybrid inheritance is supported but it may be difficult to use. In languages that separate the concurrency features from the implementation of methods, like Guide and Caromel s extension to Eiffel, it is easier to inherit the sequential part of objects. The ....

J-P. Briot and A. Yonezawa. Inheritance and Synchronization in Concurrent OOP. BIGRE, (54):35--43, June 1987.

....and scheduling control in Concurrent C [Gehani] These improvements were not easy because of the conflicts between inheritance and synchronization code. In a message based environment like actors, code for synchronization sharing and the logic of the application were affecting each other [Briot and Yonezawa 1987]. The modifications in the synchronization code usually necessitate cascaded modifications through the inheritance hierarchy [Kafura and Lee 1988, Decouchant et al. 1988] Our research has been mainly towards better languages for the realization of reactive, adaptive soft real time systems. These ....

Briot J.P. and Yonezawa A., Inheritance and Synchronization in Concurrent OOP. Proceedings of ECOOP '87, Springer Verlag LNCS 276, 1987, pp. 32-40.

....is fits well with a distributed implementation. Meanwhile, the delegation mechanism needs some non trivial synchronization mechanism to ensure the proper handling (ordering) of recursive messages, prior to other incoming messages. Thus, it may not offer a general and complete alternative solution [15]. 4.7 Evaluation of the Integrative Approach In summary, the integrative approach is very appealing by the merging it achieves between concepts, from object based programming, and those from concurrent and distributed programming. It thus provides a minimalnumber of concepts and a single ....

J.-P. Briot and A. Yonezawa, Inheritance and Synchronization in Concurrent OOP, European Conference on Object Oriented Programming (ECOOP'87), edited by J. B'ezivin, J.-M. Hullot, P. Cointe and H. Lieberman, LNCS, n o 276, Springer-Verlag, June 1987, pages 32--40.

....handling (ordering) of recursive messages, 10 As supported by Smalltalk. 11 Note that, in order to handle recursion properly, the delegated message will include the initial receiver. 11 prior to other incoming messages. Thus, it may not offer a general and complete alternative solution [BY 87] 4.7 Evaluation of the Integrative Approach In summary, the integrative approach is very appealing by the merging it achieves between concepts, from object oriented programming, and those from parallel and distributed programming. It thus provides a minimal number of concepts and a single ....

J.-P. Briot and A. Yonezawa, "Inheritance and Synchronization in Concurrent OOP," European Conference on Object Oriented Programming (ECOOP'87), edited by J. B'ezivin, J.-M. Hullot, P. Cointe and H. Lieberman, LNCS, n o 276, SpringerVerlag, June 1987, pages 32--40.

No context found.

J.-P. Briot and A. Yonezawa, Inheritance and Synchronization in Concurrent OOP, in [ECOOP 87], pages 32-40.

....is fits well with a distributed implementation. Meanwhile, the delegation mechanism needs some non trivial synchronization mechanism to ensure the proper handling (ordering) of recursive messages, prior to other incoming messages. Thus, it may not offer a general and complete alternative solution [BY 87] 4.7 Evaluation of the Integrative Approach In summary, the integrative approach is very appealing by the merging it achieves between concepts, from object oriented programming, and those from concurrent and distributed programming. It thus provides a minimal number of concepts and a single ....

J.-P. Briot and A. Yonezawa, Inheritance and Synchronization in Concurrent OOP, European Conference on Object Oriented Programming (ECOOP'87), edited by J. B'ezivin, J.-M. Hullot, P. Cointe and H. Lieberman, LNCS, n o 276, Springer-Verlag, June 1987, pages 32--40.

....is fits well with a distributed implementation. Meanwhile, the delegation mechanism needs some non trivial synchronization mechanism to ensure the proper handling (ordering) of recursive messages, prior to other incoming messages. Thus, it may not offer a general and complete alternative solution [BY 87] 3.7 Evaluation of the Integrative Approach In summary, the integrative approach is very appealing by the merging it achieves between concepts, from object oriented programming, and those from parallel and distributed programming. It thus provides a minimal number of concepts and a single ....

J.-P. Briot and A. Yonezawa, "Inheritance and Synchronization in Concurrent OOP," European Conference on Object Oriented Programming (ECOOP'87), edited by J. B'ezivin, J.-M. Hullot, P. Cointe and H. Lieberman, LNCS, n o 276, Springer-Verlag, June 1987, pages 32--40.

No context found.

J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent OOP. In European Conference on Object-Oriented Programming (ECOOP'87), volume 276 of Lecture Notes in Computer Science, pages 32--40. Springer-Verlag, 1987.

No context found.

J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent OOP. In European Conference on Object-Oriented Programming (ECOOP'87), volume 276 of Lecture Notes in Computer Science, pages 32--40. Springer-Verlag, 1987.

No context found.

J.-P. Briot and A. Yonezawa. Inheritance and synchronization in concurrent OOP. In European Conference on Object-Oriented Programming (ECOOP'87). LNCS, 276:32--40, 1987.

No context found.

J.P. Briot and A. Yonezawa, Inheritance and Synchronization in Concurrent OOP, ECOOP'87, 32-40.

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