Understandable and Scalable Concurrency

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. 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. 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. 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. Is this a good idea?

6. 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. Edward Lee’s Claim Nontrivial software written with threads, semaphores, and mutexes are incomprehensible to humans and cannot and should not be trusted!

8. What it Feels Like When I Use the synchronized Keyword in Java

9. 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. 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. 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. (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. Our rethinking: • Actor Oriented Programming Languages • Concurrent Coordination Languages • Higher order components

14. The First (?) Actor-Oriented Programming LanguageThe On-Line Graphical Specification of Computer ProceduresW. 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 object-oriented 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).

15. 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. Director from an extensible library defines component interaction semantics or “model of computation.” Extensible, behaviorally-polymorphic component library. Type system for transported data Visual editor supporting an abstract syntax Ptolemy II: A Laboratory for Actor-Oriented Models of Computation Concurrency management supporting dynamic model structure.

17. 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. 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. 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. Suppose further that we want to explicitly specify the timing of producers?

21. 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. 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. Concurrent Coordination Languages We propose to develop concurrent coordination languages based on sound, composable formalisms.

24. 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. 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. 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. Scalability: Ptalon • Ptalon (Cataldo, Cheong,Feng, Mihal, Lee) “We seek a generic language for describing higher-order configurations” Ptalon VHDL Simulink SystemC Ptolemy Credit: Adam Cataldo

28. 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. 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. 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!