This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Wrapping my head around Actors

3 replies
Jens Alfke
Joined: 2009-01-30,
User offline. Last seen 42 years 45 weeks ago.

I really like the idea of the Actor model, and I'm hoping to use it to
avoid both the endless bugs caused by multi-threading (the Java
model), and the extra complexity added by asynchronous code (the Cocoa
model). But after reading the Artima book and looking at some
examples, I'm still unsure about some things.

Actors as state machines:
An actor isn't re-entrant [right?] and can be waiting in exactly one
'react' block at any given moment, with different behaviors depending
on which message arrives. This makes it sound as though an actor can
be modeled as a finite-state machine. Is that a reasonable analysis?

Actors and deadlocks:
Yes, actor-based code is, at a high level, lockless, so it won't
deadlock. But it seems that multiple actors can get into exactly the
same situation if they go into nested 'react' blocks waiting for
responses other actors. For example, suppose actor A sends a message
to B, then goes into a nested 'react' block waiting for B's reply. B
handles the message from A by sending A a message and waiting for A's
reply before sending its reply. The two actors are now deadlocked, and
won't do any more work or process any more messages.
How does one prevent this? It seems like you'd need to think of which
actors will message which others, and make sure that cycles aren't
possible. Or is that too restrictive?

Any thoughts?

—Jens

James Iry
Joined: 2008-08-19,
User offline. Last seen 1 year 23 weeks ago.
Re: Wrapping my head around Actors


On Mon, Feb 2, 2009 at 4:34 PM, Jens Alfke <jens [at] mooseyard [dot] com> wrote:


Actors as state machines:
An actor isn't re-entrant [right?] and can be waiting in exactly one 'react' block at any given moment, with different behaviors depending on which message arrives. This makes it sound as though an actor can be modeled as a finite-state machine. Is that a reasonable analysis?

Sure, an actor is not reentrant, but it can maintain arbitrary amounts of state either in memory or externally.  And when an actor interacts with other actors, the FSM model completely breaks down.
 

Actors and deadlocks:
Yes, actor-based code is, at a high level, lockless, so it won't deadlock. But it seems that multiple actors can get into exactly the same situation if they go into nested 'react' blocks waiting for responses other actors. For example, suppose actor A sends a message to B, then goes into a nested 'react' block waiting for B's reply. B handles the message from A by sending A a message and waiting for A's reply before sending its reply. The two actors are now deadlocked, and won't do any more work or process any more messages.

Actors can both deadlock and race.  Anybody who says otherwise doesn't understand the domain.  IMHO, the important difference between actors and locking is the granularity at which these conditions can happen.

Jens Alfke
Joined: 2009-01-30,
User offline. Last seen 42 years 45 weeks ago.
Re: Wrapping my head around Actors

On Feb 2, 2009, at 6:12 PM, James Iry wrote:

> Sure, an actor is not reentrant, but it can maintain arbitrary
> amounts of state either in memory or externally. And when an actor
> interacts with other actors, the FSM model completely breaks down.

You're right; but I was talking not about the entirety of the actor's
state, but rather of just which react block it's in. For the most part
this can be represented as a state machine, with incoming messages
moving the actor from one state to another; although in practice the
actor's variables will of course influence this as well. But I suspect
it will still be a useful way to schematically represent the behavior
of an actor.

—Jens

Rich Dougherty 2
Joined: 2009-01-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Wrapping my head around Actors

On Tue, Feb 3, 2009 at 3:31 PM, Jens Alfke wrote:
> On Feb 2, 2009, at 6:12 PM, James Iry wrote:
>> Sure, an actor is not reentrant, but it can maintain arbitrary amounts of
>> state either in memory or externally. And when an actor interacts with
>> other actors, the FSM model completely breaks down.
>
> You're right; but I was talking not about the entirety of the actor's state,
> but rather of just which react block it's in. For the most part this can be
> represented as a state machine, with incoming messages moving the actor from
> one state to another; although in practice the actor's variables will of
> course influence this as well. But I suspect it will still be a useful way
> to schematically represent the behavior of an actor.

Hi Jens

Have you done any reading on how actor-based software is constructed
in Erlang? A few people in that world have done some good thinking
about this kind of thing. For example, you might be interested in a
module called "gen_fsm" that helps you model your actors as Finite
State Machines, where each message received moves the actor to a
different state. It is one example of a generic "behaviour" in Erlang.
There are other kinds too.

Joe Armstrong's thesis gives a good introduction to constructing
software in Erlang. It talks about typical behaviours and their design
rationale, including the FSM behaviour.
> http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

Everything Joe talks about is part of the Erlang/OTP library.
> http://erlang.org/doc/design_principles/part_frame.html

Jonas Bonér has ported Erlang's Supervisor behaviour to Scala.
Supervisor hierarchies are one of the most important pieces of the
puzzle when constructing reliable software in Erlang. They provide a
way to improve reliability, even in the presence of programming errors
such as deadlocks. (Although the situation is a quite bit different in
Scala, because the JVM doesn't enforce full isolation between actors
like the Erlang VM does.)
> http://jonasboner.com/2008/06/16/erlang-style-supervisor-module-for-scal...

Cheers
Rich

--
http://www.richdoughety.com/

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland