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
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
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
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
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
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
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
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