programming paradigms for concurrency
DESCRIPTION
Programming Paradigms for Concurrency. Lecture 9 Part III – Message Passing Concurrency. Classical Shared Memory Concurrency - The Downsides. shared memory typically implies physically shared memory l ocks: the “ goto statements ” of concurrency - PowerPoint PPT PresentationTRANSCRIPT
Programming Paradigms for Concurrency
Lecture 9
Part III – Message Passing Concurrency
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 expensivenumber of threads = number of available cores
≠ number of logical tasks
no natural adaptation to distributed computing
reasoning about programs is (even more) difficult
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
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 processesWe will look at one programming language in each category.
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.
The Actor Paradigm
Actors are the object-oriented approach to concurrency
“everything is an actor”
actor = object + logical thread
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
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
B
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.org
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
Scala Actors through an Example
Actor Chat
ChatRoom
session
private state
ChatClient
ChatClient
ChatClient
ChatClient
User subscribe to a chat room to receive chat messages.The chat room maintains a session of subscribers.
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.
Creating and Starting Actors
object main extends Application {val chatRoom = new ChatRoomchatRoom.start() // calls chatRoom.act
}
Communication in Actor Chat
ChatRoom
session
private state
All communication is via message passing.
Subscribeuser: User
Unsubscribeuser: User
UserPostuser: Userpost: Post
ChatClient
private state
Messages
case class User(name: String)case class Post(msg: String)
abstract class Msgcase class Subscribe(user: User) extends Msgcase class Unsubscribe(user: User) extends Msg
case class UserPost(user: User, post: Post) extends Msg
Any Scala object can serve as a messageGood practice: use immutable case classes
Defining the act Methodclass 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
Defining the act Methodclass 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
Defining the act Methodclass 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
Inplace Actor Definitionsval 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
Handling Subscriptionsvar 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 }}
Sending Messages
val chatRoom = new ChatRoomchatRoom ! Subscribe(User("Bob"))
Method ! asynchronously sends a message to the recipient.
Sending Messages
val chatRoom = new ChatRoomchatRoom !? 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.
Handling Subscriptionsvar 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
Message Timeouts with receiveWithinvar 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()
} }
} ... }}
Processing Remaining Messagesvar 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
}}
Remote Actors
Remote Actors
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
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
Event-Based Programming
Event-Based Programming
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.
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
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!
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
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 likewhile (true) { receive { ... }}
Lightweight Execution Environment
Actors (many)
Worker threads (few)Task queue
Creating Actors
T1
T2
T3
actor { // body}
closure => T3
Events generate tasks
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 TiException
1) unwinds stack of actor/worker thread
2) finishes current task
Resume in Event Mode
Ti+1
{ case Msg(x) => // handle msg}
w.t. executes Ti
Actor a suspended with
Ti+2Task Ti:...a ! Msg(42)...Task Ti+2: .apply(Msg(42))
Advanced Example
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
Hot Swapping Servercase 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] = { ... } }
Hot Swapping Servercase 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 Serverserver.startserver ! HotSwap({case Ping => println(“Ping”)})server ! Ping
Hot swapping the server:
Exception Handling and Monitoring
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
Simple Exception Handlingobject 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 ! 'helloError!
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
Error Propagationobject 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
Delegated Error Handlingval 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
More Features of Scala Actors
• Futures• Pluggable schedulers• Unique references: race-free imperative actors• ...
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
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