Understandable and Scalable Concurrency Christopher Brooks ProgrammerAnalyst University

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Bert Sutherland used the first acknowledged objectoriented framework (Sketchpad, created by his brother, Ivan Sutherland) to create the first actor-oriented programming language (which had a visual syntax). Partially constructed actor-oriented model with a class definition (top) and instance (below). Understandable and Scalable Concurrency Brooks, Lee, Berkeley 14

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

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

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

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? Understandable and Scalable Concurrency Brooks, Lee, Berkeley 18

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 Nondeterministic. Merge explicitly merges streams nondeterministically. Again a coordination language with a visual syntax. Understandable and Scalable Concurrency Brooks, Lee, Berkeley 19

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

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

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

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

Examples of Higher-Order Components ¢ ¢ ¢ Google: Map. Reduce 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 Understandable and Scalable Concurrency Brooks, Lee, Berkeley 25

Coordination languages can help with Scalability System is { Matrix(Component(2), 20, 3); } Credit: Adam Cataldo Understandable and Scalable Concurrency 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]); } Brooks, Lee, Berkeley 26

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

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

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

Conclusion ¢ Transformation of bits is the foundation of computation. Threads are the foundation of concurrent programming practice. ¢ The foundations are flawed. ¢ l l l ¢ 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. l l Actor oriented component models. Coordination languages with actor semantics. Visual syntaxes to seduce users. These have a chance of acceptance! Understandable and Scalable Concurrency Brooks, Lee, Berkeley 30