1 Concurrent ObjectOriented Programming Arnaud Bailly Bertrand Meyer
1 Concurrent Object-Oriented Programming Arnaud Bailly, Bertrand Meyer and Volkan Arslan Chair of Software Engineering
2 Lecture 5: Inheritance Anomaly. Chair of Software Engineering
In a Sequential World… § § A class is an implementation pattern. One is interested in functional behavior. A type contains operation signatures for a class. Objects offer uniform services. Chair of Software Engineering 3
In a Concurrent World… § Classes are still implementation patterns. § One is interested in interactive behavior: § the sequence of requests sent to an object, § the sequence of requests sent by an object. § A type is a state machine. § Objects offer naturally non-uniform services. Chair of Software Engineering 4
Inheritance and Subtyping § Class B inherits ( ) from Class A. § Instances a of A, b of B. § Re-usability of classes is substitution: § B subtype ( ) of A meaning § any object c can use b as if it were a. § Generally, in a sequential world: § B inherits from A implies B subtype of A. § B subtype of A implies B inherits from A. § This really not true in the concurrent world! Chair of Software Engineering 5
Inheritance Anomaly § Incremental inheritance ( ): § without redefining features of A. § Inheritance anomaly: § Depends on the notion of type and on the inheritance mechanism. Chair of Software Engineering 6
First Example § § Live routine as in POOL. Queue 2 with a deq 2() method taking 2 elements. Queue 2 is a subtype of Queue 1! Queue 2 has to redefine BODY. CLASS Queue 1… BODY DO IF empty THEN ANSWER(enq) ELSIF full THEN ANSWER(deq) ELSE ANSWER ANY FI OD YDOB CLASS Queue 2… BODY DO IF empty THEN ANSWER (enq) IF one THEN ANSWER (deq) ELSIF full THEN ANSWER (deq, deq 2) ELSE ANSWER ANY FI OD YDOB Chair of Software Engineering 7
Other Notations with Similar Problem § When synchronization is: § interwoven (monitors, delay queues), or § isolated but not separable (path expressions). § Can be further studied: § Behavior abstractions, § Enable sets, § Method guards. Chair of Software Engineering 8
Behavior Abstractions: The Good class BUFFER_LAST inherits BUFFER is public interface: … // added method Last behavior: empty_ = renames empty; partial_ = {put, get, last} redefines partial; full_ = {get, last} redefines full; implementation: Boolean is. Full, is. Empty; put (t: OBJECT) is … // INHERITED, NOT MODIFIED if (is. Full) then become full; else become partial; end; . . . OBJECT: last () is … // returns the bottom of the stack if (is. Empty) then become empty_; else become partial_; end BBUFFER; Chair of Software Engineering 9
Behavior Abstractions: The Not-So-Good class BUFFER 2 inherits BUFFER is public interface: … // as before behavior: empty_ = renames empty; one_ = {put, get} partial_ = {put, get 2} redefines partial; full_ = {get, get 2} redefines full; implementation: Boolean is. One; // added to is. Empty, is. Full put (t: OBJECT) is … if (is. Full) then become full_; if is. One then become one_; else become partial_; end; . . . // similar redefinition is necessary for get(). Couple: get 2 () is … // returns the two elements on top if (is. Empty) then become empty_; if is. One then become one_ else become partial_; end BBUFFER; Chair of Software Engineering 10
The previous anomaly… is usually called: the Partition Refinement Anomaly. Chair of Software Engineering 11
Method Guards: The Good class BBUFFER is public interface: … // as before guards: put: !is. Full() get: !is. Empty() implementation: int in, out, buf[size]; Boolean is. Full() is in = out + size end; Boolean is. Empty() is in = out end; BBUFFER (s: int) is size = s end; put (t: OBJECT) is … in : = in + 1; end; OBJECT get is … out : = out + 1; end BBUFFER; class BBUFFER 2 inherits BBUFFER is … guards: get 2: plus. One() implementation: Boolean plus. One is in >= out + 2; end; Couple get 2() is … in : = in + 2; end; Chair of Software Engineering 12
Method Guards: The Not-So-Good (1) § Method gget() may execute only after method get(). § This is called history-only sensitiveness. § The guards are not re-defined but the bodies are. class GGET_BUFFER inherits BBUFFER is … guards: gget: (after. Put = false and not is. Empty()) implementation: Boolean after. Put : = false; Object gget() is … out : = out + 1; after. Put : = false; end; // both put and get need re-definition!! put(t: Object) is … in : = in + 1; after. Put : = true end; Object get() is … in : = in + 1; after. Put : = false end; Chair of Software Engineering 13
Method Guards: The Not-So-Good (2) class LOCKER is … guards: lock: (not locked) unlock: (locked) implementation: Boolean locked : = false; lock() is locked : = true; end; unlock() is locked : = false; end; class LOCKED_BUF inherits BBUFFER, LOCKER is … guards: // need to redefine all the guards from BBUFFER!! put: (not locked and not is. Full()) get: (not locked and not is. Empty()) implementation: … // nothing changes… end; Chair of Software Engineering 14
The previous anomaly… is usually called: the Modification of Acceptable States. Chair of Software Engineering 15
Other Remedies § Either: § Based on reflective mechanisms, or § Based on automatic parallelization. § Isolate the code completely. § Try to reduce (suppress) its total amount. § When code is left, still poor on separability. § Example: Enable Sets. Chair of Software Engineering 16
References 17 § Matsuoka and Yonezawa, Analysis of Inheritance Anomaly in OOCP, in Gul Agha, Peter Wegner, Akinori Yonezawa (Editors): Research Directions in Concurrent Object-Oriented Programming. MIT Press, 1993. § Lobel Crnogorac, Anand S. Rao, Kotagiri Ramamohanarao: Classifying Inheritance Mechanisms in Concurrent Object Oriented Programming. ECOOP 1998, LNCS 1445. § Cosimo Laneve, Inheritance for Concurrent Objects, in Howard Bowman and John Derrick (Editors): Formal methods for distributed processing: a survey of object-oriented approaches. Cambridge University Press, 2001. Chair of Software Engineering
Next § Formal models and logics for concurrency. Chair of Software Engineering 18
- Slides: 18