Coordination aspect Review of AOP Summary of threads in Java COOL (COOrdination Language) Design decisions Implementation at Xerox PARC and for Demeter/Java 5/21/2019 AOO / Demeter / NU

Quote taken from Gregor Kiczales’ talk: www.parc.xerox.com/aop “To my taste the main characteristic of intelligent thinking is that one is willing and able to study in depth an aspect of one's subject matter in isolation, for the sake of its own consistency, all the time knowing that one is occupying oneself with only one of the aspects. ... Quote taken from Gregor Kiczales’ talk: www.parc.xerox.com/aop these next nine slides aren’t part of the talk per-se, they are part of the setup to it. before the talk starts, the slides are shown on the screen, going from one to the next in a loop. the purpose is to set the theme for people, of separation of concerns, of what that is about, etc. I want to make clear that it is an old idea, that it is not specific to the world of software, that there are different ways to do it… - Dijkstra, A discipline of programming, 1976 last chapter, In retrospect 5/21/2019 AOO / Demeter / NU

A few more viewgraphs taken from Gregor Kiczales’ talk www.parc.xerox.com/aop Unfortunately, I cannot post the PowerPoint source of those viewgraphs. 5/21/2019 AOO / Demeter / NU

the goal is a clear separation of concerns we want: natural decomposition concerns to be cleanly localized handling of them to be explicit in both design and implementation breaking a problem down into smaller sub-problems and then implementing those is nice, but it isn’t enough. we want more, much more: we want what we call a “clean, principled separation of concerns”. When we say that, we mean that - we want the natural concerns of the problem — in the form that is most natural to think about them — to be cleanly separated. - we’d like each to be entirely contained in one module. - more than that we want the design decisions to be explicit - more than that we want this separation to exist in both the design and the implementation 5/21/2019 AOO / Demeter / NU

achieving this requires... synergy among problem structure and design concepts and language mechanisms “natural design” “the program looks like the design” it seems to me that achieving this requires two synergies: requires that those concepts fit the concerns in the system in a natural way requires that the language mechanisms fit those concepts in a natural way these lead to two synergies… which in turn gets us what we want ——— old stuff below here when the design philosophy and the implementation mechanisms work really well together, you get this synergistic duality sort of effect, where the actual program looks like (is isomorphic to) the design. each independent concern is addressed by an independent program component. and the composition of the program units matches the decomposition in the design 5/21/2019 AOO / Demeter / NU

Cross-cutting of components and aspects better program ordinary program structure-shy functionality Components structure Aspect 1 avoid tangled programs AOP synchronization Aspect 2 5/21/2019 AOO / Demeter / NU

Demeter structure structure-shy structure-shy behavior communication compiler/ weaver structure-shy communication structure-shy behavior To many people it comes as a surprise that structure can be factored out into a separate aspect. structure-shy communication AOP: Demeter application structure-shy object description synchronization 5/21/2019 AOO / Demeter / NU

Aspect-Oriented Programming components and aspect descriptions High-level view, implementation may be different Source Code (tangled code) From Gregor: maybe source code should say: intermediate source code add: picture of a preprocessor style implementation of an AOP system not all AOP systems will be preprocessor like. It is reasonable to expect that in the future the better ones won’t be this is a picture of what AOP is equivalent to, not necessarily how it works. general AOP weaver (compile- time) 5/21/2019 AOO / Demeter / NU

Technology Evolution Object-Oriented Programming Law of Demeter dilemma Tangled structure/behavior Adaptive Programming Other tangled code Aspect-Oriented Programming 5/21/2019 AOO / Demeter / NU

Components/Aspects of Demeter Functionality (structure-shy) Traversal (Traversal Strategies) Functionality Modification (Visitors) Structure (UML class diagrams) Description (annotated UML class diagrams, class dictionaries) Synchronization more details on Demeter aspects 5/21/2019 AOO / Demeter / NU

Threads ! Thread 1 Thread 2 5/21/2019 AOO / Demeter / NU

Coordination aspect Put coordination code about thread synchronization in one place. Threads are synchronized through methods. Method synchronization Exclusion sets Method managers 5/21/2019 AOO / Demeter / NU

Java Threads Thread class in Standard Java libraries Thread worker = new Thread() start method spawns a new thread of control based on Thread object. start invokes the threads run method: active thread 5/21/2019 AOO / Demeter / NU

Java Threads synchronized method: locks object. A thread invoking a synchronized method on the same object must wait until lock released. Mutual exclusion of two threads. class Account { synchronized double getBalance() { return balance;} synchronized void deposit(double a) { balance += a;} } 5/21/2019 AOO / Demeter / NU

Java Threads synchronized statements synchronized (expr) statement lock an object without invoking a synchronized method expr must produce an object to lock 5/21/2019 AOO / Demeter / NU

Java Threads communication between threads with wait and notify (defined in class Object). cliché: synchronized void doWhenCondition() { while (!condition) wait(); do_it(); } 5/21/2019 AOO / Demeter / NU

Java Threads notify: after change of data that some other thread is waiting on synchronized void changeCondition(){ // change some value notifyall(); // wakes all waiting threads } 5/21/2019 AOO / Demeter / NU

Problem with synchronization code: it is tangled with component code class BoundedBuffer { Object[] array; int putPtr = 0, takePtr = 0; int usedSlots = 0; BoundedBuffer(int capacity){ array = new Object[capacity]; } 5/21/2019 AOO / Demeter / NU

Tangling synchronized void put(Object o) { while (usedSlots == array.length) { try { wait(); } catch (InterruptedException e) {}; } array[putPtr] = o; putPtr = (putPtr +1 ) % array.length; if (usedSlots==0) notifyall(); usedSlots++; // if (usedSlots++==0) notifyall(); The if (usedSlots == 0) is used for efficiency reasons so that other threads are only notified if the buffer switches from empty to nonempty 5/21/2019 AOO / Demeter / NU

Solution: tease apart basics and synchronization write core behavior of buffer write coordinator which deals with synchronization use weaver which combines them together simpler code replace synchronized, wait, notify and notifyall by coordinators 5/21/2019 AOO / Demeter / NU

With coordinator: basics Using Demeter/Java, *.beh file With coordinator: basics BoundedBuffer { public void put (Object o) (@ array[putPtr] = o; putPtr = (putPtr+1)%array.length; usedSlots++; @) public Object take() (@ Object old = array[takePtr]; array[takePtr] = null; takePtr = (takePtr+1)%array.length; usedSlots--; return old; @) 5/21/2019 AOO / Demeter / NU

Coordinator Using Demeter/COOL, put into *.cool file coordinator BoundedBuffer { selfex put, take; mutex {put, take} condition empty=true, full=false; exclusion sets coordinator variables 5/21/2019 AOO / Demeter / NU

Coordinator method managers with requires clauses and entry/exit clauses put requires (!full) { on exit {empty=false; if (usedSlots==array.length) full=true; }} take requires (!empty) { on exit {full=false; if (usedSlots==0) empty=true; }} } 5/21/2019 AOO / Demeter / NU

exclusion sets selfex A.f,B.g; mutex {g,h,i} mutex {f,k,l} only one thread can call a selfex method A.f and B.g may run simultaneously. mutex {g,h,i} mutex {f,k,l} if a thread calls a method in a mutex set, no other thread may call a method in the same mutex set. 5/21/2019 AOO / Demeter / NU

Multi-class coordination supported coordinator A, B { selfex A.put, B.take; mutex {B.put, A.take} condition empty=true, full=false; ... 5/21/2019 AOO / Demeter / NU

Design decisions behind COOL The smallest unit of synchronization is the method. The provider of a service defines the synchronization (monitor approach). Coordination is contained within one coordinator. Association from object to coordinator is static. 5/21/2019 AOO / Demeter / NU

Design decisions behind COOL Deals with thread synchronization within each execution space. No distributed synchronization. Coordinators can access the objects’ state, but they can only modify their own state. Synchronization does not “disturb” objects. Currently a design rule not checked by implementation. 5/21/2019 AOO / Demeter / NU

COOL Provides means for dealing with mutual exclusion of threads, synchronization state, guarded suspension and notification coordinator ! Thread 1 Thread 2 5/21/2019 AOO / Demeter / NU

COOL Identifies “good” abstractions for coordinating the execution of OO programs coordination, not modification of the objects mutual exclusion: sets of methods preconditions on methods coordination state (history-sensitive schemes) state transitions on coordination 5/21/2019 AOO / Demeter / NU

COOL Shape plain Java public class Shape { coordinator Shape { protected double x_ = 0.0; protected double y_ = 0.0; protected double width_ = 0.0; protected double height_ = 0.0; double x() { return x_(); } double y() { return y_(); } double width(){ return width_(); } double height(){ return height_(); void adjustLocation() { x_ = longCalculation1(); y_ = longCalculation2(); void adjustDimensions() { width_ = longCalculation3(); height_ = longCalculation4(); coordinator Shape { selfex {adjustLocation, adjustDimensions} mutex {adjustLocation,x} mutex {adjustLocation,y} mutex {adjustDimensions, width} height} } 5/21/2019 AOO / Demeter / NU

Programming with COOL Protocol object/coordinator: 1 1: method invocation coordinator 2 2: request presented to the coordinator 3 3: coordinator checks synchronization state, eventually suspending thread; when thread can proceed,coordinator performs “on_entry” actions 7 7: coordinator performs “on_exit” actions 8 8: method returns 4 4: request proceeds to the object 6 6: return is presented to coordinator 5 5: method execution m() {…} object 5/21/2019 AOO / Demeter / NU

COOL View of Classes Stronger visibility: Limited actions: coordinator can access: all methods and variables of its classes, independent of access control all non-private methods and variables of their superclasses Limited actions: only read variables, not modify them only coordinate methods, not invoke them 5/21/2019 AOO / Demeter / NU

Programming with COOL Implementing COOL Implementation Semantics Xerox PARC Implemention object coordinator m() {…} 1 2 4 5 6 3 8 Implementation 7 Implementing COOL Programming with COOL coordinator 3 7 8 2 4 6 5 m() {…} 1 object Semantics 5/21/2019 AOO / Demeter / NU

COOL public class BoundedBuffer { coordinator BoundedBuffer { private Object array[]; private int putPtr = 0, takePtr = 0; private int usedSlots = 0; public BoundedBuffer(int capcty){ array = new Object[capcty]; } public void put(Object o) { array[putPtr] = o; putPtr = (putPtr+1)%array.length; usedSlots++; public Object take() { Object old = array[takePtr]; array[takePtr] = null; takePtr = (takePtr+1)%array.length; usedSlots--; return old; coordinator BoundedBuffer { selfex {put, take} mutex {put, take}; boolean full=(@ false @), empty=(@ true @); put requires (@ !full @) { on exit (@ empty = false; if (usedSlots==array.length) full = true; @) } take requires (!empty){ full = false; if (usedSlots == 0) empty = true; 5/21/2019 AOO / Demeter / NU

Implementing COOL BoundedBuffer BoundedBufferCoord 2 5 3 4 6 1 7 8 _dcoord // rest of the variables protected void _d_put(Object o){ //implementation code } public void put(Object o) { _dcoord.enter_put(this); try { _d_put(o); } finally { _dcoord.exit_put(this); protected Object _d_take() { public Object take() { //similar to put // variable next page synchronized void enter_put(BoundedBuffer o){ // ... } exit_put(BoundedBuffer o) { enter_take(BoundedBuffer o){ exit_take(BoundedBuffer o) { 2 4 5 3 1 6 7 8 5/21/2019 AOO / Demeter / NU

Implementing COOL class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots()==o._dget_size()) full=true; notifyAll(); ... 5/21/2019 AOO / Demeter / NU

Implementing COOL to keep track of method execution state class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots() == o._dget_size()) full = true; notifyAll(); ... 5/21/2019 AOO / Demeter / NU

One class to support COOL class MethodState { int depth = 0; Vector t1 = new Vector(); final public boolean isBusyByOther() { if (depth > 0 && !t1.contains(Thread.currentThread())) return true; else return false;} final public void in() { depth++; t1.addElement(Thread.currentThread());} final public void out() { depth--; …} 5/21/2019 AOO / Demeter / NU

Implementing COOL coordination vars class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots()==o._dget_size()) full=true; notifyAll(); ... coordination vars 5/21/2019 AOO / Demeter / NU

Implementing COOL conditions for waiting class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots() == o._dget_size()) full = true; notifyAll(); ... Implementing COOL conditions for waiting 5/21/2019 AOO / Demeter / NU

Implementing COOL update method state class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots() == o._dget_size()) full = true; notifyAll(); ... update method state 5/21/2019 AOO / Demeter / NU

Implementing COOL update method state class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots() == o._dget_size()) full = true; notifyAll(); ... update method state 5/21/2019 AOO / Demeter / NU

Implementing COOL on_exit statements class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots()==o._dget_size()) full=true; notifyAll(); ... on_exit statements 5/21/2019 AOO / Demeter / NU

Implementing COOL notify state change class BoundedBufferCoord { MethState put = new MethState(); MethState take = new MethState(); boolean empty = true, full = false; public synchronized void enter_put(BoundedBuffer o) { while (put.isBusyByOtherThread() || take.isBusyByOtherThread() || full) { try { wait(); } catch (InterruptedException e) {} } put.in(); public synchronized void exit_put(BoundedBuffer o) { put.out(); empty = false; if (o._dget_usedlots()==o._dget_size()) full=true; notifyAll(); ... Implementing COOL notify state change 5/21/2019 AOO / Demeter / NU

Acknowledgments Many of the viewgraphs prepared by Crista Lopes for her Ph.D. work supported by Xerox PARC. Implementation of COOL for Demeter/Java by Josh Marshall. Integration into Demeter/Java with Doug Orleans. ECOOP ‘94 paper on synchronization patterns by Lopes/Lieberherr. 5/21/2019 AOO / Demeter / NU