1. Understandable and Scalable Concurrency Christopher Brooks Programmer/Analyst, University of California, Berkeley Edward A. Lee Robert S. Pepper Distinguished Professor, Chair, Department of Electrical Engineering and Computer Sciences, University of California, Berkeley Citris/HP Labs meeting, Palo Alto January 16, 2007

2. Brooks, Lee, Berkeley 2Understandable and Scalable Concurrency Introductions Edward Lee would like to be here, but had a resource contention problem. I’m a software release engineer, training electrical engineers in the art of software engineering. I’ve worked with Edward since 1992, first on Ptolemy Classic (C++) and now on Ptolemy II (Java).

3. Brooks, Lee, Berkeley 3Understandable and Scalable Concurrency Concurrency in Software Practice, As of 2007 Threads Shared memory, semaphores, mutexes, monitors… Message Passing Synchronous, asynchronous, buffered, … Everything else, regrettably, remains largely in the domain of research…

4. Brooks, Lee, Berkeley 4Understandable and Scalable Concurrency The Buzz “Multicore architectures will (finally) bring parallel computing into the mainstream. To effectively exploit them, legions of programmers must emphasize concurrency.” The vendor push: “Please train your computer science students to do extensive multithreaded programming.”

5. Brooks, Lee, Berkeley 5Understandable and Scalable Concurrency Is this a good idea?

6. Brooks, Lee, Berkeley 6Understandable and Scalable Concurrency The Problem with Threads IEEE Computer, May 2006 article “For concurrent programming to become mainstream,... we must discard threads as a programming model”. “Nondeterminism should be judiciously and carefully introduced when needed,... and it should be explicit in programs.”

7. Brooks, Lee, Berkeley 7Understandable and Scalable Concurrency Edward Lee’s Claim Nontrivial software written with threads, semaphores, and mutexes are incomprehensible to humans and cannot and should not be trusted!

8. Brooks, Lee, Berkeley 8Understandable and Scalable Concurrency What it Feels Like When I Use the synchronized Keyword in Java

9. Brooks, Lee, Berkeley 9Understandable and Scalable Concurrency Why should HP care about concurrency? If a multicore machine with an HP logo crashes, then people will not blame Intel or AMD. First, they will blame Microsoft. Then, they will blame HP.

10. Brooks, Lee, Berkeley 10Understandable and Scalable Concurrency The Following are Only Partial Solutions Training programmers to use threads. Improve software engineering processes. Devote attention to “non-functional” properties. Use design patterns. None of these deliver a rigorous, analyzable, and understandable model of concurrency.

11. Brooks, Lee, Berkeley 11Understandable and Scalable Concurrency 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).

12. Brooks, Lee, Berkeley 12Understandable and Scalable Concurrency (Semi) Succinct Solution Statement Instead of starting with a wildly nondeterministic mechanism and asking the programmer to rein in that nondeterminism, start with a deterministic mechanism by using deterministic, composable components and incrementally add nondeterminism where needed. Under this principle, even the most effective of today’s techniques (OO design, transactions, message passing, …) require fundamental rethinking.

13. Brooks, Lee, Berkeley 13Understandable and Scalable Concurrency Our rethinking: Actor Oriented Programming Languages Concurrent Coordination Languages Higher order components

14. Brooks, Lee, Berkeley 14Understandable and Scalable Concurrency The First (?) Actor-Oriented Programming Language The On-Line Graphical Specification of Computer Procedures W. R. Sutherland, Ph.D. Thesis, MIT, 1966 MIT Lincoln Labs TX-2 Computer Bert Sutherland with a light pen Partially constructed actor-oriented model with a class definition (top) and instance (below). Bert Sutherland used the first acknowledged object- oriented framework (Sketchpad, created by his brother, Ivan Sutherland) to create the first actor-oriented programming language (which had a visual syntax).

15. Brooks, Lee, Berkeley 15Understandable and Scalable Concurrency Examples of Actor-Oriented “Languages” CORBA event service (distributed push-pull) ROOM and UML-2 (dataflow, Rational, IBM) VHDL, Verilog (discrete events, Cadence, Synopsys,...) LabVIEW (structured dataflow, National Instruments) Modelica (continuous-time, constraint-based, Linkoping) OPNET (discrete events, Opnet Technologies) SDL (process networks) Occam (rendezvous) Simulink (Continuous-time, The MathWorks) SPW (synchronous dataflow, Cadence, CoWare) … Many of these are domain specific. Many of these have visual syntaxes.

16. Brooks, Lee, Berkeley 16Understandable and Scalable Concurrency Ptolemy II: A Laboratory for Actor- Oriented Models of Computation Director from an extensible library defines component interaction semantics or “model of computation.” Extensible, behaviorally- polymorphic component library. Visual editor supporting an abstract syntax Type system for transported data Concurrency management supporting dynamic model structure.

17. Brooks, Lee, Berkeley 17Understandable and Scalable Concurrency Observer Pattern using an Actor-Oriented Language with Rendezvous Semantics 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.

18. Brooks, Lee, Berkeley 18Understandable and Scalable Concurrency Now that we’ve made a trivial design pattern trivial, we can work on more interesting aspects of the design. E.g., suppose we don’t care how long notification of the observer is deferred, as long as the observer is notified of all changes in the right order?

19. Brooks, Lee, Berkeley 19Understandable and Scalable Concurrency Observer Pattern using an Actor-Oriented Language with Kahn Semantics (Extended with Nondeterministic Merge) Each actor is a process, communication is via streams, and the NondeterministicMerge explicitly merges streams nondeterministically. Again a coordination language with a visual syntax.

20. Brooks, Lee, Berkeley 20Understandable and Scalable Concurrency Suppose further that we want to explicitly specify the timing of producers?

21. Brooks, Lee, Berkeley 21Understandable and Scalable Concurrency Observer Pattern using an Actor-Oriented Language with Discrete Event Semantics Messages have a (semantic) time, and actors react to messages chronologically. Merge now becomes deterministic. Again a coordination language with a visual syntax.

22. Brooks, Lee, Berkeley 22Understandable and Scalable Concurrency Coordination Languages Coordination Languages don’t have syntax for mundane operations like arithmetic expressions (unlike Erlang and Ada). Coordination languages have been around for awhile (Papadopoulos & Arbab, 1998) Failed because they are not general purpose, one cannot write a compiler in them, adherents to Coordination Languages are traitors.

23. Brooks, Lee, Berkeley 23Understandable and Scalable Concurrency Concurrent Coordination Languages We propose to develop concurrent coordination languages based on sound, composable formalisms.

24. Brooks, Lee, Berkeley 24Understandable and Scalable Concurrency Scalability The key to composition languages are configurations with higher-order parameters These parameters enable reuse They also enable small descriptions of big systems Credit: Adam Cataldo

25. Brooks, Lee, Berkeley 25Understandable and Scalable Concurrency Examples of Higher-Order Components Google: MapReduce VHDL: Recursive Structures Bluespec System Verilog: Parameterization Dataflow: Higher-Order Systems Petri-nets: Higher-Order Tokens Liberty Simulation Environment: Higher-Order Parameters Credit: Adam Cataldo

26. Brooks, Lee, Berkeley 26Understandable and Scalable Concurrency Coordination languages can help with Scalability System is { Matrix(Component(2),20,3); } Component is { param n; port in[n*2+1]; port out[n*2+2]; } in { Blue(n, in[1..n*2], out[1..n*2]); Green(n, in[n*2+1], out[n*2+1]); } Credit: Adam Cataldo

27. Brooks, Lee, Berkeley 27Understandable and Scalable Concurrency Scalability: Ptalon Ptalon (Cataldo, Cheong, Feng, Mihal, Lee) “We seek a generic language for describing higher-order configurations” Ptalon VHDL Ptolemy SystemC Simulink Credit: Adam Cataldo

28. Brooks, Lee, Berkeley 28Understandable and Scalable Concurrency The Solution Actor-oriented component architectures implemented in coordination languages that complement rather than replace existing languages. With good design of these coordination languages, this will deliver understandable concurrency. See the Ptolemy Project for explorations of several such languages: http://ptolemy.org

29. Brooks, Lee, Berkeley 29Understandable and Scalable Concurrency Time Line and Management Plan Year 1: Use Ptolemy II to create coordination languages with existing domains. Teach a graduate course in concurrency Year 2: Codification of useful higher-order components Develop visual syntax for higher-order comps. Year 3: Demonstrate combining coordination langs. Code Generator for concurrent programs Introduce undergrads to coordination langs.

30. Brooks, Lee, Berkeley 30Understandable and Scalable Concurrency Conclusion Transformation of bits is the foundation of computation. Threads are the foundation of concurrent programming practice. The foundations are flawed. Threads discard the most essential features of computation. Threads are incomprehensible to humans. They appeal because they make (almost) no changes to syntax. Concurrent computation needs a new foundation. Actor oriented component models. Coordination languages with actor semantics. Visual syntaxes to seduce users. These have a chance of acceptance!