Concurrent Computational Systems

1. Concurrent Computational Systems Edward A. Lee Professor, UC Berkeley Ptolemy Project CHESS: Center for Hybrid and Embedded Software Systems University of Arizona Distinguished Lecture SeriesJanuary 13, 2005 Tuscon, Arizona

2. Abstract Prevailing software abstractions are deeply rooted in the sequential imperative model, which at its root, is poorly matched to concurrent systems. Threads are a widely used natural extension of these abstractions to concurrent problems. Semaphores and mutual exclusion locks provide synchronization primitives offering some control over the relative timing of actions in threads. In this talk, I will argue that nontrivial concurrent programs based on threads, semaphores, and mutual exclusion locks are incomprehensible. I will outline a family of alternative concurrent models of computation, such as discrete events, process networks, synchronous languages, and dataflow, that promise more comprehensible programs. Most of these have been around for some time, and some of them have achieved widespread usage, but generally not in mainstream software. Indeed, several of them offer promising views of "computation" in a broader sense than the Turing-Church sense. They promise a view of computation that embraces mixed hardware-software systems and embedded systems that engage the physical world.

3. Standard Software Abstraction(20-th Century Computation) initial state sequence f : State  State Alan Turing final state • Time is irrelevant • All actions are ordered

4. Standard Software Abstraction: Processes or Threads • The operating system (typically) provides: • suspend/resume • mutual exclusion • semaphores Infinite sequences of state transformations are called “processes” or “threads” suspend resume

5. Standard Software Abstraction:Concurrency via Interacting Threads Potential for race conditions, deadlock, and livelock severely compromises software reliability. These methods date back to the 1960’s (Dijkstra). stalled by precedence race condition stalled for rendezvous

6. A Stake in the Ground Nontrivial concurrent programs based on threads, semaphores, and mutexes are incomprehensible to humans. • No amount of process improvement is going to change this. • the human brain doesn’t work this way. • Formal methods may help • scalability? • understandability? • Better concurrency abstractions will help more

7. A Story: Ptolemy Project Code Review

8. Ptolemy Project Code ReviewA Typical Story • Code review discovers that a method needs to be synchronized to ensure that multiple threads do not reverse each other’s actions. • No problems had been detected in 4 years of using the code. • Three days after making the change, users started reporting deadlocks caused by the new mutex. • Analysis and correction of the deadlock is hard. • But code review successfully identified the flaw.

9. Code Review Doesn’t Always WorkAnother Typical Story /** CrossRefListisalistthatmaintainspointerstootherCrossRefLists. … @authorGeroncioGalicia,Contributor:EdwardA.Lee @version$Id:CrossRefList.java,v1.782004/04/2914:50:00ealExp$ @sincePtolemyII0.2 @Pt.ProposedRatingGreen(eal) @Pt.AcceptedRatingGreen(bart) */ publicfinalclassCrossRefListimplementsSerializable{ … protectedclassCrossRefimplementsSerializable{ … // NOTE: It is essential that this method not be // synchronized, since it is called by _farContainer(), // which is. Having it synchronized can lead to // deadlock. Fortunately, it is an atomic action, // so it need not be synchronized. privateObject_nearContainer(){ return_container; } privatesynchronizedObject_farContainer(){ if(_far!=null)return_far._nearContainer(); elsereturnnull; } … } } Code that had been in use for four years, central to Ptolemy II, with an extensive test suite, design reviewed to yellow, then code reviewed to green in 2000, causes a deadlock during a demo on April 26, 2004.

10. And Doubts Remain /** CrossRefListisalistthatmaintainspointerstootherCrossRefLists. … @authorGeroncioGalicia,Contributor:EdwardA.Lee @version$Id:CrossRefList.java,v1.782004/04/2914:50:00ealExp$ @sincePtolemyII0.2 @Pt.ProposedRatingGreen(eal) @Pt.AcceptedRatingGreen(bart) */ publicfinalclassCrossRefListimplementsSerializable{ … protectedclassCrossRefimplementsSerializable{ … privatesynchronizedvoid_dissociate(){ _unlink();// Remove this. // NOTE: Deadlock risk here! If _far is waiting // on a lock to this CrossRef, then we will get // deadlock. However, this will only happen if // we have two threads simultaneously modifying a // model. At the moment (4/29/04), we have no // mechanism for doing that without first // acquiring write permission the workspace(). // Two threads cannot simultaneously hold that // write access. if(_far!=null)_far._unlink();// Remove far } } Safety of this code depends on policies maintained by entirely unconnected classes. The language and synchronization mechanisms provide no way to talk about these systemwide properties.

11. What it Feels Like to Use the synchronized Keyword in Java Image “borrowed” from an Iomega advertisement for Y2K software and disk drives, Scientific American, September 1999.

12. Diagnosis: Interacting Processes are Not Compositional An aggregation of processes is not a process (a total order of external interactions). What is it? Many software failures are due to this ill-defined composition.

13. Distributed Version of 20-th Century Computation Force-fitting the sequential abstraction onto parallel hardware. remote procedure call

14. Combining Processes and RPC – Split-Phase Execution, Futures,Asynchronous Method Calls, Callbacks, … These methods are at least as incomprehensible as concurrent threads or processes. “asynchronous” procedure call

15. Better Concurrency Models Better concurrency models exist. We examine a family of such models that we call actor-oriented models.

16. Traditional component interactions: class name What flows through an object is sequential control data methods call return Actor oriented: actor name What flows through an object is streams of data data (state) parameters ports Output data Input data What is an Actor-Oriented MoC?

17. Director from a library defines component interaction semantics Large, domain-polymorphic component library. Type system for transported data Visual editor supporting an abstract syntax Ptolemy II: Framework for Experimenting with Actor-Oriented Models of Computation Basic Ptolemy II infrastructure:

18. The Basic Abstract Syntax • Actors • Attributes on actors (parameters) • Ports in actors • Links between ports • Width on links (channels) • Hierarchy • Concrete syntaxes: • XML • Visual pictures • Actor languages (Cal, StreamIT, …)

19. Hierarchy - Composite Components dangling Relation Port Actor opaque Port Port transparent or opaqueCompositeActor toplevel CompositeActor

20. Abstract Semanticsof Actor-Oriented Models of Computation • Actor-Oriented Models of Computation that we have implemented: • dataflow (several variants) • process networks • distributed process networks • Click (push/pull) • continuous-time • CSP (rendezvous) • discrete events • distributed discrete events • synchronous/reactive • time-driven (several variants) • … execution control data transport init() fire()

21. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking Most of these are actor oriented.

22. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking

23. DE Director implements timed semantics using an event queue Example Model of Computation:Discrete Events (DE) Reactive actors Event source Signal Time line

24. Semantics Clears Up Subtleties: E.g. Simultaneous Events By default, an actor produces events with the same time as the input event. But in this example, we expect (and need) for the BooleanSwitch to “see” the output of the Bernoulli in the same “firing” where it sees the event from the PoissonClock. Events with identical time stamps are also ordered, and reactions to such events follow data precedence order.

25. Semantics Clears Up Subtleties: E.g. Feedback Data precedence analysis has to take into account the non-strictness of this actor (that an output can be produced despite the lack of an input).

26. Semantics Clears Up Subtleties: E.g. Zeno Systems DE systems may have an infinite number of events in a finite amount of time. Carefully constructed semantics gives these systems meaning.

27. A Rough Sense of Discrete-Event Semantics: Metric Space Formulation Cantor metric: where t is the earliest time where x and y differ. The set of signals with this metric form a complete metric space. x y Generalizations of this metric handle multiple events at the same time. t

28. Causality in DE Causal: Strictly causal: Delta causal: A delta-causal component is a “contraction map.”

29. Fixed Point Theorem(Banach Fixed Point Theorem) Let (S n= [T  V]n, d ) be a complete metric space and f : S n S nbe a delta causal function. Then f has a unique fixed point, and for any point s  S n, the following sequence converges to that fixed point: s1= s, s2= f (s1), s3= f (s2), … This means no Zeno! Current work: Other formulations (using generalized ultrametric spaces, ordinals, and posets) give meaning to a broader class of systems.

30. Semantic Challenges Create distributed discrete-event systems. Three families of techniques are known: • Conservative techniques (Chandy & Misra) • Optimistic techniques (Time warp, Jefferson) • Distributed consensus (Croquet, Reed)

31. Application of DE ModelingWireless Sensor Nets in VisualSense VisualSense extends the Ptolemy II discrete-event domain with communication between actors representing sensor nodes being mediated by a channel, which is another actor. The example at the left shows a grid of nodes that relay messages from an initiator (center) via a channel that models a low (but non-zero) probability of long range links being viable.

32. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking

33. Example Model of ComputationContinuous Time (CT) Director implements a “solver” that constructs an approximation to the continuous-time behavior. A signal has a value at all real-valued times. Integrator used to define systems governed by ordinary differential equations.

34. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking

35. Heterogeneous ModelsHybrid Systems: CT + FSM The FSM director can be combined with other directors to create modal models.

36. Semantic Subtleties In hybrid systems, signals may have more than one value at a given time. • Discontinuities • Transient states • Traditional mathematical formulation of a signal:x: Reals Realsnhas to be modified:x: Reals  Naturals Realsnwith ensuing consequences for the theory.

37. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking

38. Heterogeneous ModelsMixed Signals: DE + CT DE signal DE model of a digital controller CT signal CT model of mechanical system

39. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking

40. Example Untimed Model of Computation:Process Networks (PN) actor == thread signal == stream reads block writes don’t Kahn, MacQueen, 1977

41. PN Semantics • A signal is a sequence of values • Define a prefix order: x y means that x is a prefix of y. • Actors are monotonic functions: x y  F(x) F(y) • Stronger condition: Actors are continuous functions (intuitively: they don’t wait forever to produce outputs).

42. PN Semantics of Composition (Kahn, ’74) If the components are deterministic, the composition is deterministic. • Knaster-Tarski fixed point theorem: • Continuous function has a unique least fixed point • Execution procedure for finding that fixed point • Successive approximations to the fixed point

43. Semantic Subtleties • Giving semantics to finite sequences in combination with infinite sequences. • Unifying fixed-point semantics with metric-space semantics (in order to give meaning to heterogeneous models that combine timed with untimed systems).

44. Application of PN and Ptolemy IIKepler – Scientific Workflows Led by San Diego Supercomputer Center (SDSC), with participation from the SEEK ITR, DOE SciDAC SDM, and others, researchers are building on Ptolemy II a distributed workflow system called Kepler to “provide access to any resource, any data, any service, anytime, anywhere” via a distributed computing platform (aka the “Grid”) supporting “high performance computing, and federated, integrated, mediated databases within a user-friendly workbench / problem-solving environment.” This effort is compatible with the objectives of NSF Cyberinfrastructure, UK’s e-Science Programme, and DOE’s SciDAC (Scientific Discovery through Advanced Computing).

45. Kepler Example: Harvesting Web Services Example showing a web service wrapper (Thanks to Bertram Ludaecher, San Diego Supercomputer Center)

46. Kepler Example: Grid Computations Thanks toBertram LudäscherSDSC

47. ORB Kepler Example:Real-Time Data Feeds Thanks to Bertram Ludäscher, SDSC This model integrates real-time data feeds from a ship (the Roger Revelle)

48. Ilkay Altintas SDM, Resurgence Kim Baldridge Resurgence, NMI Chad Berkley SEEK Shawn Bowers SEEK Terence Critchlow SDM Tobin Fricke ROADNet Jeffrey Grethe BIRN Christopher H. Brooks Ptolemy II Zhengang Cheng SDM Dan Higgins SEEK Efrat Jaeger GEON Matt Jones SEEK Werner Krebs, EOL Edward A. Lee Ptolemy II Kai Lin GEON Bertram Ludaescher SEEK, GEON, SDM, BIRN, ROADNet Mark Miller EOL Steve Mock NMI Steve Neuendorffer Ptolemy II Jing Tao SEEK Mladen Vouk SDM Xiaowen Xin SDM Yang Zhao Ptolemy II Bing Zhu SEEK ••• KEPLER/CSP: Contributors, Sponsors, Projects(or loosely coupled Communicating Sequential Persons ;-) Ptolemy II Thanks to Bertram Ludäscher, SDSC

49. Models of ComputationImplemented in Ptolemy II • CI – Push/pull component interaction • Click – Push/pull with method invocation • CSP – concurrent threads with rendezvous • CT – continuous-time modeling • DE – discrete-event systems • DDE – distributed discrete events • DDF – Dynamic dataflow • DPN – distributed process networks • DT – discrete time (cycle driven) • FSM – finite state machines • Giotto – synchronous periodic • GR – 2-D and 3-D graphics • PN – process networks • SDF – synchronous dataflow • SR – synchronous/reactive • TM – timed multitasking

50. Synchronous Models of Computation Director finds a value (or absent) at each “tick” of a global clock Feedback is resolved by finding a fixed point. Semantic foundation based on Kanster-Tarski fixed point theorem on Scott topologies. Signal has a value or is absent at each tick of the “clock.”