Ptolemy Project Vision Edward A Lee Robert S

Ptolemy Project Vision Edward A. Lee Robert S. Pepper Distinguished Professor and Chair of EECS, UC Berkeley 7 th Biennial Ptolemy Miniconference Berkeley, CA February 13, 2007

Concurrent Composition of Subsystems, In Mainstream SW Engineering, As of 2007 ¢ Component technologies l l ¢ Concurrency l l ¢ Objects in C++, C#, or Java Wrappers as service definitions Threads (shared memory, semaphores, mutexes, …) Message Passing (synchronous or not, buffered, …) Distributed computing l Distributed objects wrapped in web services, Soap, CORBA, DCOM, … Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 2

Observations Threads and objects dominate SW engineering. l l Threads: Sequential computation with shared memory. Objects: Collections of state variables with procedures for observing and manipulating that state. Even distributed objects create the illusion of shared memory through proxies. l l l The components (objects) are (typically) not active. Threads weave through objects in unstructured ways. This is the source of many software problems. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 3

To Examine the Problems With Threads and Objects, Consider a Simple Example “The Observer pattern defines a one-to-many dependency between a subject object and any number of observer objects so that when the subject object changes state, all its observer objects are notified and updated automatically. ” Design Patterns, Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley Publishing Co. , 1995. ISBN: 0201633612): Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 4

Observer Pattern in Java public void add. Listener(listener) {…} public void set. Value(new. Value) { my. Value = new. Value; for (int i = 0; i < my. Listeners. length; i++) { my. Listeners[i]. value. Changed(new. Value) } } Will this work in a multithreaded context? Thanks to Mark S. Miller for the details of this example. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 5

Observer Pattern With Mutual Exclusion (Mutexes) public synchronized void add. Listener(listener) {…} public synchronized void set. Value(new. Value) { my. Value = new. Value; for (int i = 0; i < my. Listeners. length; i++) { my. Listeners[i]. value. Changed(new. Value) } } Javasoft recommends against this. What’s wrong with it? Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 6

Mutexes are Minefields public synchronized void add. Listener(listener) {…} public synchronized void set. Value(new. Value) { my. Value = new. Value; for (int i = 0; i < my. Listeners. length; i++) { my. Listeners[i]. value. Changed(new. Value) } } value. Changed() may attempt to acquire a lock on some other object and stall. If the holder of that lock calls add. Listener(), deadlock! Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 7

After years of use without problems, a Ptolemy Project code review found code that was not thread safe. It was fixed in this way. Three days later, a user in Germany reported a deadlock that had not shown up in the test suite. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 8

Simple Observer Pattern Becomes Not So Simple public synchronized void add. Listener(listener) {…} public void set. Value(new. Value) { while holding lock, make copy synchronized(this) { of listeners to avoid race my. Value = new. Value; conditions listeners = my. Listeners. clone(); notify each listener outside of } synchronized block to avoid deadlock for (int i = 0; i < listeners. length; i++) { listeners[i]. value. Changed(new. Value) } } Ptolemy Miniconference, February 13, 2007 This still isn’t right. What’s wrong with it? Lee, Berkeley 9

Simple Observer Pattern: How to Make It Right? public synchronized void add. Listener(listener) {…} public void set. Value(new. Value) { synchronized(this) { my. Value = new. Value; listeners = my. Listeners. clone(); } for (int i = 0; i < listeners. length; i++) { listeners[i]. value. Changed(new. Value) } } Suppose two threads call set. Value(). One of them will set the value last, leaving that value in the object, but listeners may be notified in the opposite order. The listeners may be alerted to the value changes in the wrong order! Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 10

If the simplest design patterns yield such problems, what about non-trivial designs? /** Cross. Ref. List is a list that maintains pointers to other Cross. Ref. Lists. … @author Geroncio Galicia, Contributor: Edward A. Lee @version $Id: Cross. Ref. List. java, v 1. 78 2004/04/29 14: 50: 00 eal Exp $ @since Ptolemy II 0. 2 @Pt. Proposed. Rating Green (eal) @Pt. Accepted. Rating Green (bart) Code that had been in */ public final class Cross. Ref. List implements Serializable { use for four years, … central to Ptolemy II, protected class Cross. Ref implements Serializable{ with an extensive test … // NOTE: It is essential that this method not be suite with 100% code // synchronized, since it is called by _ far. Container(), coverage, design // which is. Having it synchronized can lead to reviewed to yellow, then // deadlock. Fortunately, it is an atomic action, // so it need not be synchronized. code reviewed to green private Object _near. Container() { in 2000, causes a return _container; deadlock during a demo } private synchronized Object _far. Container() { if (_far != null) return _far. _near. Container(); else return null; } … on April 26, 2004. } } Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 11

Our Claim Nontrivial software written with threads, semaphores, and mutexes are incomprehensible to humans. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 12

Perhaps Concurrency is Just Hard… Sutter and Larus observe: “humans are quickly overwhelmed by concurrency and find it much more difficult to reason about concurrent than sequential code. Even careful people miss possible interleavings among even simple collections of partially ordered operations. ” H. Sutter and J. Larus. Software and the concurrency revolution. ACM Queue, 3(7), 2005. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 13

If concurrency were intrinsically hard, we would not function well in the physical world It is not concurrency that is hard… Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 14

…It is Threads that are Hard! Threads are sequential processes that share memory. From the perspective of any thread, the entire state of the universe can change between any two atomic actions (itself an ill-defined concept). Imagine if the physical world did that… Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 15

Succinct Problem Statement Threads are wildly nondeterministic. The programmer’s job is to prune away the nondeterminism by imposing constraints on execution order (e. g. , mutexes) and limiting shared data accesses (e. g. , OO design). Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 16

Do Threads Have a Sound Foundation? If the foundation is bad, then we either tolerate brittle designs that are difficult to make work, or we have to rebuild from the foundations. Note that this whole enterprise is held up by threads Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 17

Our Solution: Actor-Oriented Design The established: Object-oriented: class name What flows through an object is sequential control data methods call return Things happen to objects The alternative: Actor oriented: actor name data (state) parameters ports Input data Actors make things happen What flows through an object is evolving data Output data Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 18

Succinct Solution Statement: Actor-Oriented Coordination Languages Each actor is a process, communication is via rendezvous, and the Merge explicitly represents nondeterministic multi-way rendezvous. This is realized here in a coordination language with a visual syntax. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 19

A Rich Design Space In this solution, the Observer need not keep up with nor block the value producers or consumer. The Java solution never got this level of design … Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 20

Potential for Timed Semantics In this solution, timing is specified. Timed models of computation have enormous potential for embedded systems. Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 21

Research Directions of the Ptolemy Project ¢ Real-time systems l ¢ Concurrent software l ¢ Understandable, scalable concurrency, service-oriented architectures, distributed computing Scalable composition of subsystems l ¢ Distributed real-time software, PRET machines, robust software, wireless sensor networks Integration technologies, higher-order components, supervisory models, interface formalisms, data models Hybrid systems l Integration of SR, DE, and CT Ptolemy Miniconference, February 13, 2007 Lee, Berkeley 22

Acknowledgements ¢ Current students l l l l ¢ ¢ Elaine Cheong Thomas Huining Feng ¢ Jackie (Man-Kit) Leung Eleftherios Matsikoudis ¢ Yang Zhao (to Oracle) Haiyang Zheng (to Math. Works) Gang Zhou Rachel Zhou (to Marvell) Staff l l l Christopher Brooks Tracey Richards Mary Stewart Recent Ph. D graduates l l Recent masters graduates l Shamik Bandyopadhyay Current sponsors l l l Ptolemy Miniconference, February 13, 2007 Adam Cataldo (Agilent) Xiaojun Liu (Sun Microsystems) Air Force Research Labs (AFRL) Air Force Office of Scientific Research (AFOSR) Army Research Office (ARO) Agilent California MICRO Program DGIST Hewlett-Packard Microsoft National Instruments National Science Foundation (NSF) Toyota Lee, Berkeley 23