Chair of Software Engineering 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 3 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 4 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 5 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 6 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 7 First Example  Live routine as in POOL.  Queue2 with a deq2() method taking 2 elements.  Queue2 is a subtype of Queue1!  Queue2 has to redefine BODY. CLASS Queue1… BODY DO IF empty THEN ANSWER(enq) ELSIF full THEN ANSWER(deq) ELSE ANSWER ANY FI OD YDOB CLASS Queue2… BODY DO IF empty THEN ANSWER (enq) IF one THEN ANSWER (deq) ELSIF full THEN ANSWER (deq, deq2) ELSE ANSWER ANY FI OD YDOB

Chair of Software Engineering 8 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 9 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 isFull, isEmpty; put (t: OBJECT) is … // INHERITED, NOT MODIFIED if (isFull) then become full; else become partial; end;... OBJECT: last () is … // returns the bottom of the stack if (isEmpty) then become empty_; else become partial_; end; end BBUFFER;

Chair of Software Engineering 10 Behavior Abstractions: The Not-So-Good class BUFFER2 inherits BUFFER is public interface: … // as before behavior: empty_= renames empty; one_= {put, get} partial_= {put, get, get2}redefines partial; full_= {get, get2}redefines full; implementation: Boolean isOne; // added to isEmpty, isFull put (t: OBJECT) is … if (isFull) then become full_; if isOne then become one_; else become partial_; end;... // similar redefinition is necessary for get(). Couple: get2 () is … // returns the two elements on top if (isEmpty) then become empty_; if isOne then become one_ else become partial_; end; end BBUFFER;

Chair of Software Engineering 11 The previous anomaly… is usually called: the Partition Refinement Anomaly.

Chair of Software Engineering 12 Method Guards: The Good class BBUFFER is public interface: … // as before guards: put: !isFull() get: !isEmpty() implementation: int in, out, buf[size]; Boolean isFull() is in = out + size end; Boolean isEmpty() 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; end BBUFFER; class BBUFFER2 inherits BBUFFER is … guards: get2: plusOne() implementation: Boolean plusOne is in >= out + 2; end; Couple get2() is … in := in + 2; end; end;

Chair of Software Engineering 13 Method Guards: The Not-So-Good (1) class GGET_BUFFER inherits BBUFFER is … guards: gget: (afterPut = false and not isEmpty()) implementation: Boolean afterPut := false; Object gget() is … out := out + 1; afterPut := false; end; // both put and get need re-definition!! put(t: Object) is … in := in + 1; afterPut := true end; Object get() is … in := in + 1; afterPut := false end; end;  Method gget() may execute only after method get().  This is called history-only sensitiveness.  The guards are not re-defined but the bodies are.

Chair of Software Engineering 14 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; end; class LOCKED_BUF inherits BBUFFER, LOCKER is … guards: // need to redefine all the guards from BBUFFER!! put: (not locked and not isFull()) get: (not locked and not isEmpty()) implementation: … // nothing changes… end;

Chair of Software Engineering 15 The previous anomaly… is usually called: the Modification of Acceptable States.

Chair of Software Engineering 16 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 17 References  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,  Lobel Crnogorac, Anand S. Rao, Kotagiri Ramamohanarao: Classifying Inheritance Mechanisms in Concurrent Object Oriented Programming. ECOOP 1998, LNCS  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 18 Next  Formal models and logics for concurrency.