Thursday, June 04, 2009

2009-06-04 Thursday - JavaOne 2009 - Actor-Based Concurrency in Scala

Session: TS-5395, "Actor-Based Concurrency in Scala"

Phillipp Haller, EPFL
Frank Sommers, Artima

Actor Principles:
- Shared-nothing
-- Actor's state is private
-- No synchronization on private state

- Actors communicate through messages
-- Messages are (mostly) immutable objects

- Actors can be local or remote
-- Same programming model
-- Scales "from multicore to cloud"

An established concurrency paradigm
Long history of research
-- started at MIT in the 70's (Hewitt, Agha)
--- insipred by Smalltalk and Simula

- Motivation for the development for Scheme

Actors in Erlang
"a pure message-passing language"
- Supportive language features
- Special, process-oriented virtual machine
-- Manage VM processes
-- Cheap proceses: creates them fast, have lots of them
- OTP: library of Erlang modules for building reliable distributed systems

Actors in Scala
- Closest implementation of the Erlang model on the JVM
- Leverages Scala language features
-- pattern matching, closures
-- traits and mutliple inheritance
-- Full Java interoperability
- Event-based Actors
-- Not tied to Java threads
-- allows you to scale to millions of Actors / Threads
- Local and remote
-- same programming model
- Implementable as an embedded DSL
- Part of Scala's standard library
-- scala.actors, scala.actors.remote
- used by Twitter's kestrel message system (?)

Creating an Actor
- extend class by Actor class
- implement act() method
- define message types (case classes)
- Receiving messages, use the "receive" command

WOW - I get Actors now

Pattern matching: switch on steroids

- List of alternatives:
-- case pattern => expression
- Patterns are tried in order, the first match is evaluated
- Patterns look like factory method calls

Handling subscriptions

Sending a subscription message:
chatroom ! Subscribe(User("bob"))

"!" method to send a message
Nono-blocking, returns immediately
Implicity passes a reference to the sender

Syncrhonous send
val res = chatRoom !? Subscribe(User("bob"))

"!?" sychronous send method
Blocks sender until reply is received

Futures (callback?)
val future = chatRoom !! Subscribe(User("bob"))

Message send does not block
Future: handle that represents the reply
Sender waits for the....?

Timeouts: receiveWithin(ms)
self.receiveWithin (1800 * 1000)

Scala Actors work across Virtual Machines - using remote Actors
import RemoteActor._

Sending message to remote Actors
, 8000), 'chatRoom)

select returns a proxy to the Actor
Reference to caller transfers to remote node:
- sender is valid reference in remote Actor

Event-based (aka thread-less) Actors
Event-based actors do not consume a thread while waiting for a message
- receive {} with react{}
- receiveWithin {} with reactWithin() {}
- while(cond) {} with loopWhile(cond) {}
Massive gains in scalability

Event-based (aka thread-less) Actors

Receive vs. react
- Use react whenever possible
- Use receive when necessary (e.g. to receive a value returned by an Actor)

Act II: Under the hood
- Event-based actors
-- decoupling threads and actors
- Lightweight execution environment
-- work-stealing thread pool
- Implementing the DSL
-- Creating actors using actor {}
-- Receiving messages using react {}

Event-based Actors
- Naive thread-per-actor implementation
-- thread creation and context-swtiching overhead
-- high memory consumption
- Implementation in Scala Actors is event-driven
-- Decouple actors from JVM threads
-- Execute actors on thread pool

Lightweight execution environment
- Thread pool
- Work stealing
-- Load balancing
- Local work queues

Thread pools and work stealing
-- map Actors (man) to Thread Pool
-- worker threads (few)

JSR 166 thread pool implementation (?)

Implementing the DSL
Creating Actors

Starting an Actor cretes a task that is submitted to a scheduler managing a thread pool.

Customizing Actor execution

Executing Actors on the AWT event dispatch thread

Scala 2.8 and beyond
- pluggable schedulers
- integrating exceptions and Erlang-style error handling
- Continuations support
-- using optional compiler-plugin
-- More flexible control structures, Actor migration
- Static checking: @immutable, Actor isolation

No comments: