1. Programming Paradigms for Concurrency Lecture 9 Part III – Message Passing Concurrency

2. Classical Shared Memory Concurrency - The Downsides shared memory typically implies physically shared memory locks: the “goto statements” of concurrency OS threads are resource-hungry and context-switching is expensive number of threads = number of available cores ≠ number of logical tasks number of threads = number of available cores ≠ number of logical tasks no natural adaptation to distributed computing reasoning about programs is (even more) difficult

3. Message Passing Concurrency no shared-memory (in its pure form) + some classes of concurrency errors avoided by design + natural programming model for distributed architectures - less efficient on shared-memory architectures: data must be copied before sending synchronization between processes is explicit + reasoning about program behavior is simplified - some say: it’s harder to parallelize a sequential program using MP higher level of abstraction + decoupling between computation tasks and physical threads possible -> event-based programming

4. Message Passing Paradigms Two important categories of MP paradigms: 1.Actor or agent-based paradigms  unique receivers: messages are sent directly from one process to another 2.Channel-based paradigms – multiple receivers: messages are sent to channels that are shared between processes We will look at one programming language in each category.

5. Reading Material Actors in Scala. Haller and Sommers, Artima, to appear 2011 (preprint available). Concurrent Programming in ML. Reppy, Cambridge University Press, 1999. Communicating and Mobile Systems: The Pi Calculus. Milner, Cambridge University Press, 1999. Additional material will be posted on the lecture web site.

6. The Actor Paradigm Actors are the object-oriented approach to concurrency “everything is an actor” actor = object + logical thread

7. A Brief History of Actors Hewitt, Bishop, Steiger 1973: proposal of actors Greif 1975: operational semantics Baker, Hewitt 1977: axiomatic semantics Lieberman, Theriault 1981: Act-1 language Clinger 1981: denotational semantics Agha 1986: transition semantics … Armstrong et al. 1990s: Erlang language … Haller, Odersky 2007: actors in the Scala language

8. Actors in a Nutshell actors perform local computations and communicate via MP communication is – asynchronous – buffered (unordered in theory but FIFO in practice) – over unique-receiver channels (mailboxes) – restricted to “known” actors computation is – even-driven: react to incoming messages – dynamically create other actors – send messages to other actors – dynamically change behavior languages supporting actor-based concurrency – Erlang – Salsa – Scala – many implementations in form of libraries A A A A B B

9. The Scala Language unifies object-oriented and functional programming concepts – mixin class composition – higher-order functions – algebraic data types + pattern matching – closures statically typed (type system based on System F) interoperable with Java (compiles to the JVM) enables embedding of rich domain-specific languages Open-source: available from http://www.scala-lang.orghttp://www.scala-lang.org

10. Scala Actors [Haller, Odersky, 2007] Scala library extension for high-level concurrent programming – part of the Scala standard library pair of message receive operations ( receive / react ) – allows trade-off between efficiency and flexibility – react enables event-based programming without inversion of control message handlers as first-class partial functions – enables extension of actor behavior wide adoption – Lift web framework – Twitter

11. Scala Actors through an Example

12. Actor Chat ChatRoom session private state ChatClient User subscribe to a chat room to receive chat messages. The chat room maintains a session of subscribers.

13. Defining Actors import scala.actors.Actor class ChatRoom extends Actor { def act() { // the actor’s behavior } Actors are regular Scala objects that extend the Actor trait.

14. Creating and Starting Actors object main extends Application { val chatRoom = new ChatRoom chatRoom.start() // calls chatRoom.act }

15. Communication in Actor Chat ChatRoom session private state All communication is via message passing. Subscribe user: User Subscribe user: User Unsubscribe user: User Unsubscribe user: User UserPost user: User post: Post UserPost user: User post: Post ChatClient private state

16. Messages case class User(name: String) case class Post(msg: String) abstract class Msg case class Subscribe(user: User) extends Msg case class Unsubscribe(user: User) extends Msg case class UserPost(user: User, post: Post) extends Msg Any Scala object can serve as a message Good practice: use immutable case classes Any Scala object can serve as a message Good practice: use immutable case classes

17. Defining the act Method class ChatRoom extends Actor { def act() { while (true) { receive { case Subscribe(user) => // handle subscription message case Unsubscribe(user) => // handle unsubscribe request case UserPost(user, post) => // handle a post from a user } Actor reacts to incoming message via the receive method of the Actor trait receive takes a partial function f as argument Defines a closure f

18. Defining the act Method class ChatRoom extends Actor { def act() { while (true) { receive { case Subscribe(user) => // handle subscription message case Unsubscribe(user) => // handle unsubscribe request case UserPost(user, post) => // handle a post from a user } f maps incoming messages to the corresponding action performed by the actor f is matched against the messages in the actor’s mailbox Defines a closure f

19. Defining the act Method class ChatRoom extends Actor { def act() { while (true) { receive { case Subscribe(user) => // handle subscription message case Unsubscribe(user) => // handle unsubscribe request case UserPost(user, post) => // handle a post from a user } the first message on which f is defined is received unmatched messages remain in the mailbox if no message matches, receive blocks until a matching message is received Defines a closure f

20. Inplace Actor Definitions val chatRoom = actor { while (true) { receive { case Subscribe(user) => // handle subscription message case Unsubscribe(user) => // handle unsubscribe request case UserPost(user, post) => // handle a post from a user } closure defines act method of chatRoom

21. Handling Subscriptions var session = Map.empty[Actor, Actor] while (true) { receive { case Subscribe(user) => val sessionHandler = actor { while (true) { self.receive { case Post(msg) => // forward message to subscribers } session = session + (subsriber -> sessionHandler) // handle UserPost and Unsubscribe message }

22. Sending Messages val chatRoom = new ChatRoom chatRoom ! Subscribe(User("Bob")) Method ! asynchronously sends a message to the recipient.

23. Sending Messages val chatRoom = new ChatRoom chatRoom !? Subscribe(User("Bob")) match { case response: String => println(response) } Method !? asynchronously sends a message and then blocks until a reply message has been received from the recipient.

24. Handling Subscriptions var session = Map.empty[Actor, Actor] while (true) { receive { case Subscribe(user) => val subscriber = sender val sessionHandler = actor { while (true) { self.receive { case Post(msg) => subscriber ! Post(msg) } session = session + (subscriber -> sessionHandler) reply(“subscribed: “ + user.name) // handle UserPost and Unsubscribe message } address of the sender of matched message sends message to sender

25. Message Timeouts with receiveWithin var session = Map.empty[Actor, Actor] while (true) { receive { case Subscribe(user) => val (subscriber, room) = (sender, self) val sessionHandler = actor { while (true) { self.receiveWithin (1800 * 1000) { case Post(msg) => for (key <- session.keys; if key != subscriber) session(key) ! Post(msg) case TIMEOUT => room ! Unsubscribe(user) case ‘die => self.exit() } }... }

26. Processing Remaining Messages var session = Map.empty[Actor, Actor] while (true) { receive { // handle Subscribe message case Unsubscribe(user) => session(sender) ! ‘die session = session – sender case UserPost(user, msg) => session(sender) ! msg }

27. Remote Actors

28. Remote actors enable transparent communication between Scala actors over networks import scala.actors.Actor._ import scala.actors.remote.RemoteActor._ class ChatRoom(port: Int) extends Actor { def act() { alive(port) register(‘chatRoom, self) //... } attach this actor to given port register given symbol with given actor

29. Remote Actors Remote actors enable transparent communication between Scala actors over networks import scala.actors.Actor._ import scala.actors.remote.RemoteActor._ class ChatClient(chatURL: String, chatPort: Int) extends Actor { def act() { val node = Node(chatURL, chatPort) val chatRoom = select(node, ‘chatRoom) chatRoom ! Subscribe(User(“Bob”)) //... } obtain local interface to remote actor

30. Event-Based Programming

31. receive binds an actor to a dedicated JVM thread  if receive blocks, so does the dedicated thread of the blocking actor  each actor (blocking or nonblocking) needs its own thread  scales badly with the number of actors, since JVM threads are resource hungry Scala actors provide an alternative to receive, which enables event-based programming.

32. receive vs. react react behaves like receive but with a different waiting strategy.  if react blocks, the actor is suspended and its dedicated thread released for processing events of other actors  event-based programming with react scales to large numbers of actors

33. Event-Based Programming with react class ChatRoom extends Actor { def act() { while (true) { react { case Subscribe(user) => // handle subscription message case Unsubscribe(user) => // handle unsubscribe request case UserPost(user, post) => // handle a post from a user } never returns!

34. Event-Based Programming with react class ChatRoom extends Actor { def act(): Unit = { react { case Subscribe(user) => // handle subscription message act() case Unsubscribe(user) => // handle unsubscribe request act() case UserPost(user, post) => // handle a post from a user act() } closure must encompass full continuation of the actor

35. Or Simpler... class ChatRoom extends Actor { def act() { loop { react { case Subscribe(user) => // handle subscription message case Unsubscribe(user) => // handle unsubscribe request case UserPost(user, post) => // handle a post from a user } special combinators for composing react blocks behaves like while (true) { receive {... }} behaves like while (true) { receive {... }}

36. Lightweight Execution Environment Actors (many) Worker threads (few) Task queue

37. Creating Actors T1T1 T2T2 T3T3 actor { // body } closure => T 3 Events generate tasks

38. Suspend in Event Mode def react(f: PartialFunction[Any, Unit]): Nothing = { mailbox.dequeueFirst(f.isDefinedAt) match { case None => continuation = f; suspended = true case Some(msg) =>... } throw new SuspendActorException }... react { case Msg(x) => // handle msg } Task T i Exception 1)unwinds stack of actor/worker thread 2)finishes current task Exception 1)unwinds stack of actor/worker thread 2)finishes current task

39. Resume in Event Mode T i+1 { case Msg(x) => // handle msg } w.t. executes T i Actor a suspended with T i+2 Task T i :... a ! Msg(42)... Task T i+2 :.apply(Msg(42))

40. Advanced Example

41. Code Hot Swapping payload of a message can be arbitrary scala object actors can send new behavior to other actors enables dynamic reconfiguration of actor behavior

42. Hot Swapping Server case class HotSwap(code: PartialFunction[Any, Unit]) class Server extends Actor { def act = loop { react { genericBase orElse actorBase } } private def actorBase: PartialFunction[Any, Unit] = hotswap getOrElse body private var hotswap: Option[PartialFunction[Any, Unit]] = None private val genericBase: PartialFunction[Any, Unit] = { case HotSwap(code) => hotswap = code } def body: PartialFunction[Any, Unit] = {... } }

43. Hot Swapping Server case class HotSwap(code: PartialFunction[Any, Unit]) class Server extends Actor {... private val genericBase: PartialFunction[Any, Unit] = { case HotSwap(code) => hotswap = Some(code) } case object Ping... val server = new Server server.start server ! HotSwap({case Ping => println(“Ping”)}) server ! Ping Hot swapping the server:

44. Exception Handling and Monitoring

45. Actors and Exceptions act method of an actor may throw exceptions unhandled exceptions do not seep out of the throwing actor but unhandled exceptions terminate the throwing actor  other actors might wait for messages from actors that died silently  may cause deadlocks that are hard to debug

46. Simple Exception Handling object A extends Actor { def act() { react { case 'hello => throw new Exception("Error!") } override def exceptionHandler = { case e: Exception => println(e.getMessage()) } scala> A.start() scala> A ! 'hello Error! scala> A.start() scala> A ! 'hello Error!

47. Monitoring Actors Actor library provides special support for monitoring the life cycle of (a group of) actors: exit(reason) : terminates this actor link(otherActor) : links this actor with otherActor In case of termination/uncaught exceptions, exit is called implictely. Calls to exit are propagated to all linked actors. Enables error propagation delegated error handling fault tolerance

48. Error Propagation object Master extends Actor { def act() { Slave ! 'doWork receive { case 'done => throw new Exception("Master crashed") } object Slave extends Actor { def act() { link(Master) while (true) { receive { case 'doWork => println("Done") reply('done) } Slave terminates, if Master crashes or terminates

49. Delegated Error Handling val a = actor { receive { case 'start => val somethingBadHappened =... // some error condition if (somethingBadHappened) throw new Exception("Error!") println("Nothing bad happened") } val b = actor { self.trapExit = true link(a) a ! 'start receive { case Exit(from, reason) if from == a => println("Actor 'a' terminated because of " + reason) } calls to a ’s exit method are converted to Exit messages in b ’s mailbox

50. More Features of Scala Actors Futures Pluggable schedulers Unique references: race-free imperative actors...

51. Further Reading For more details about Scala actors see Actors in Scala. Haller and Sommers, Artima, to appear 2011 (preprint available) Tutorial on Scala web page Scala actors: Unifying thread-based and event- based programming. Haller and Odersky, Theoretical Computer Science, 2008 Dissertation of Philipp Haller, EPFL, Switzerland, 2010

52. Outlook next week – Channel-based message passing concurrency – Concurrent ML: first-class synchronous events after Christmas – formal semantics of MP programs: process calculi – formal reasoning about MP programs