Is my description of the actor model right?

Question

If I understood, the actor model is just like the object model, but with a few differences:

1. EVERY object spawns it's own separate thread and its not a problem even when you have thousands of objects.
2. Actors don't interact by calling functions and getting return values but instead by sending and receiving messages.
3. If you don't violate that model your app will be using concurrency to its full power without any risks of race conditions.
4. Everything you can do in OO you can do using actors but better, the problem being that everything we coded in the last years was OO based - but a transition is imminent.

So for instance, suppose I have to define 3d vector class/actor, create two instance and call a sum operation on them.

OBJECT ORIENTED:

class V3d {
   constructor V3d(x,y,z) //bla
   float x,y,z;
   function sum(V3d b) 
   { 
      return V3d(x+b.x,y+b.y,z+b.z); 
   }
}

//using:
mySum = V3d(1,2,3).sum(V3d(3,2,1)) //creates 2 instances, sum, returns instantly
drawPoint(mySum) //uses the result

ACTOR MODEL:

actor V3d 
{
    constructor V3d(x,y,z) //bla
    float x,y,z;
    loop 
    {
       receive 'sum',b:V3d :
           send(caller,'sumResult',V3d(x+b.x,y+b.y,z+b.z))
    }
 }

//using:
send(V3d(1,2,3),'sum',V3d(3,2,1)) //creates 2 instances, send to the first one a request to sum with the second one

loop 
{
   receive 'sumResult',result:
      drawPoint(result) //receives result and draws it
}

Is that it? Or am I completely wrong?

Answer 1

The short answer is no, it's not correct.

1. starts reasonably correct (each Actor at least potentially executes as an independent thread), but then largely goes off the rails. There's nothing about the model that makes lots of threads work well -- that's up to the implementation. At most, the ease of creating lots of threads puts pressure on the implementation to provide efficient threading. At least as far as the model cares, any resemblance between actors and objects is mostly coincidental. "Object" carries fairly specific implications about how you combine code and data. An actor will generally involve both code and data, but implies little about how they're combined (other than the fact that the only data visible to the outside world is messages).

2. The usual way of describing the interaction is as message sending, yes. I don't have a citation handy, but somebody proved quite a long time ago that mechanisms like C++ virtual functions are isomorphic to message sending (as virtual functions are normally implemented, you're using an offset into a vtable -- but if you sent an offset into a table of messages instead, the effect would be the same).

3. It's not quite that simple. If you can find a copy, Henry Baker (with somebody else whose name I don't remember right now) wrote a paper about the rules necessary for data consistency in the Actor model.

4. "Better" is highly subjective at best. Some problems are highly parallel in nature, and really do involve a large number of essentially autonomous entities, with minimal interaction that's primarily asynchronous. When that's the case, the actor model can work very well indeed. For other problems, that's really not the case. Some problems are almost entirely serial in nature. Others can be executed in parallel, but still require close synchronization between those actions (e.g., essentially a SIMD-like mode, where you execute one instruction at a time, but each instruction acts on on a large number of data items). It's certainly possible to solve both of these types of problems using the actor model -- but for such problems, it often involves a fair amount of extra work for little or no gain in return.

Answer 2

Regarding 1: I have worked with single(ish) threaded Actor-modeled application, so it's quite possible to disregard the large thread number this suggests. AFAIK, threads are not lightweight objects by any means, so it's probably not desirable to have one for each actor, depending on how many actors you are using.

Regarding 3: I'm pretty sure race conditions can happen in actor modeled systems simply due to programming logic?

Regarding 4: Define 'better'? My experience has been that asynchronous logic can be much more difficult to read than synchronous stuff. e.g, in your example above, you don't know which operation is responsible for which result, so there is extra message tracking to do. Once that is added in and other messages in and out are included in the logic, the intent of the code is spread across several send/receive functions.

Having said all of that, I am a big fan of actor model use for the upper layers of an application. It can make decoupling easier, since adding dependencies is a bit harder than adding a function. I also don't have much experience with higher level than Java languages, and other paradigms might support asynchronous-ness in a more fundamental way.