Presentation for term paper for CSC 464 Concurrency, in Victoria, in April 2008. Slideshare removed the photos, here's a PDF version https://dl.dropboxusercontent.com/u/169716/csc464-project/Comparing%20Implementations%20of%20the%20Actor%20Model.pdf

1. Concurrency Summit 2008
Comparing
implementations of
the Actor Model
Jim Roepcke
<jr@uvic.ca>
1

2. Actor models?
2

3. This kind?
3

4. No, not that kind...
4

5. The kind in Joe
Armstrong’s Erlang,
5

6. The kind in Joe
Armstrong’s Erlang,
6

7. Evan Phoenix’s
Rubinius,
7

8. Martin Odersky’s
Scala,
8

9. and Steve Dekorte’s
Io.
9

10. What is the
Actor Model?
10

11. It’s a trendy
model for
concurrent
programming
11

12. Massively parallel future
• The future has begun!
• We had lots of time to
figure this out
• Programmers are still
using threads and
mutexes in “high
level” code
• Bad programmer!
• ABSTRACTION FTW!
12

13. What’s old is new again
• Actors defined by Hewitt in 1973
• More work by his PhD students in the
80s, Clinger, Agha
• Adopted by Erlang in the late 80s for
the telecom industry
• Picking up steam as concurrency
becomes a hot issue again
13

14. Actors win because
they are simple
14

15. Actors communicate
15

16. Actors spawn
16

17. Actors run in parallel
17

18. Actors listen
18

19. Actors avoid deadlock
19

20. Actors perform great!
20

21. Now: up close
21

22. Comparing
Actors to Actors
• Implemented a program in Erlang,
Rubinius, Scala and Io
• My experiences with each
22

23. OM NOM NOM!
• Implemented the
“burger problem”
from CSC 464
Assignment 1 in all
four languages
23

24. spawn!
supervisor
24

25. mmm
hungry
Student
Student Student
Burger
burger!
Student Student
enjoy!
Order Line Burger Line
ok
k Cook Cook Burger Burger
supervisor 25

26. Actors communicate
26

27. Communication
• Asynchronous Message Passing
• Encourages no memory sharing
• Each actor has a “mailbox” which
queues messages sent
• “send” mechanism to deliver a
message to an actor
27

28. Sending messages
Erlang Rubinius
pid ! message actor << message
Scala Io
actor ! message obj @@method(args)
28

29. Actors and burgers
29

30. Actors spawn
30

31. Creating actors
• To create concurrency, actors create
more actors and send them messages
• Actors are independently executing
entities
31

32. Creating actors
Erlang Rubinius
pid = spawn(fun) actor = Actor.spawn ...
Scala
Io
sa = new SomeActor()
sa := SomeActor clone
sa.start()
32

33. Erlang Actors
• Actors are called processes
• Process creation and context
switching is very fast and lightweight
• Processes cannot share memory
• Typically run a tail-recursive function
33

34. Rubinius Actors
• Actor class comes with Rubinius VM
• Green Ruby thread per actor
• VM assigns a Mailbox per thread
• Remote Actors new, not perfect yet
• “Orders of magnitude” worse than
Erlang: Rubinius developer on IRC
34

35. Scala Actors
• scala.actors package comes with Scala
• Hybrid execution model, actors run in
their own thread or via events
• Claim massive scalability using events
and thread pools
• Remote Actors supported
• act() loops to stay alive
35

36. Io Actors
• Io uses coroutines for concurrency
• Scheduling is FIFO, no prioritization
• One kernel thread per VM, async I/O
• @@ runs the method on a dedicated
per-object coroutine for messages
• Remote actors not supported
36

37. Actors run in parallel
37

38. Parallelism: Erlang
• SMP Erlang automatically puts
processes on different cores/CPUs
• Messaging actors in remote VMs is
seamless
• spawn(Node, fun) to spawn an actor
on a different VM which may be
remote
38

39. Parallelism: Rubinius
• One kernel thread per Rubinius VM
• Processor affinity for multi-core?
• Use VMActor to create an actor on a
remote VM
• Messaging actors in remote VMs is
seamless thanks to duck typing
39

40. Parallelism: Scala
• When using event-based actors, Scala
creates multple threads to balance
load across cores
• Use RemoteActor class to find an actor
on a different VM
• Messaging actors in remote VMs is
seamless
40

41. Parallelism: Io
• Nope :-(
• One kernel
thread per VM
• No support for
remote actors
built-in
41

42. Actors listen
42

43. Receiving messages
• Take a message off the mailbox queue
• Decide if you want to deal with it
• Messages are data
• Timeouts
43

44. Receiving messages
Erlang
loop(State) -> % a tail-recursive function
receive
{hello, From} ->
greet(From), loop(State)
ping ->
doPingThing(), loop(State)
{goodbye, From} ->
From ! {kthxbye, self(), State} % no loop
after 100
loop(State+1) % inc # of timeouts
end.
44

45. Receiving messages
Rubinius
def actor_process()
looping = true
while looping
Actor.receive do |filter|
filter.when Hello do |message|
greet(message.from)
end
filter.when Goodbye do |message|
message.from << KThxBye[self]
looping = false
end
end
end
45

46. Receiving messages
Scala
def act()
loop {
receive {
case Hello(from) => greet(from)
case Ping() => doPingThing()
case Goodbye(from) => {
from ! KThxBye(self)
exit()
}
}
}
}
46

47. Receiving messages
Io
MyActor := Object clone
MyActor hello := method(from, greet(from))
MyActor ping := method(doPingThing)
MyActor goodbye := method(from,
from @@kthxbye(self)
)
anActor := MyActor clone // create actor instance
anActor @@hello(self)
anActor @@ping
anActor @@goodbye(self) // look ma, no loops!
47

48. Actors avoid deadlock
48

49. No locks, no dead
• Agha(1985) says the semantics of the
Actor model mean that deadlock
doesn’t exist in a syntactic sense
• Semantic deadlock can be detected
and removed easily using wait-for
graphs
49

50. Actors perform great!
50

51. Fine grained, hot CPU
• Lightweight context switching
• Actors don’t suffer from locking
granularity issues because there are
no locks
• Actors can run “full out” on as many
CPUs/machines as the underlying
language can make available
51

52. Conclusion
• Light, fast processes needed to see
huge scalability
• Erlang’s the fastest and most mature
(see OTP)
• You can’t sneeze in the JVM without
declaring it’s chemical composition
• Io is a beautiful little language
52

53. “erlang is nice,
because
everything
just works”
Paul Jenkins
April 11, 2008
53

54. What next?
• Iolang... Io with:
• Support for multiple cores
• Easy way: one VM per core?
• Selective receive
• Support for remote actors
54

55. No cows were hurt...
55

56. Thanks for listening
Picture credits
Billie Joe: http://flickr.com/photos/15034493@N00/112357008/sizes/l/
Joe Armstrong: http://flickr.com/photos/mbiddulph/2037845171/sizes/l/
Evan Phoenix: http://flickr.com/photos/scoop/1403258349/sizes/o/
Steve Dekorte: http://flickr.com/photos/x180/276960722/sizes/o/
Martin Odersky: http://picasaweb.google.com/JavaPolis.com/JavaPolis2007/photo#5144254997958003122
Bruno: http://www.smh.com.au/ffximage/2006/10/31/bruno_wideweb__470x329,0.jpg
Coady: http://flickr.com/photos/sebastian_bergmann/116486823/sizes/o/
Ships: http://flickr.com/photos/lesec/361956524/sizes/o/
Jim: http://flickr.com/photos/kteague/278136366/sizes/o/
LOLcode: http://flickr.com/photos/i-marco/534996407/sizes/o/
Triplets: http://flickr.com/photos/origamijoel/217238954/sizes/l/
Spawn: http://flickr.com/photos/austenhaines/399622840/
Parallel runners: http://flickr.com/photos/moodeous/205711924/sizes/o/
Microscopic: http://flickr.com/photos/braid44/2232461763/sizes/o/
Emoburger: http://flickr.com/photos/gx9/269025682/
Cow: http://flickr.com/photos/66164549@N00/542696674/sizes/o/
icanhascheezburger: http://icanhascheezburger.com/2007/01/11/i-can-has-cheezburger/
56

57. Questions
Make it quick, Paul’s next
57

58. Dedicated to
Cheryl, Cyan,
Xavier, and
Justin
58