[ACCEPTED]-When should one use the Actor model?-actor-model

Given some concurrency problem, what would 45 you look for to decide whether to use actors 44 or not?

First I would look to define the 43 problem... is the primary motivation a speedup 42 of a nested for loop or recursion? If so 41 a simple task based approach or parallel 40 loop approach will likely work well for 39 you (rather than actors).

However if you 38 have a more complex system that involves 37 dependencies and coordinating shared state, then 36 an actor approach can help. Specifically 35 through use of actors and message passing 34 semantics you can often avoid using explicit 33 locks to protect shared state by actually 32 making copies of that state (messages) and 31 reacting to them.

You can do this quite easily 30 with the classic synchronization problems 29 like dining philosophers and the sleeping 28 barbers problem. But you can also use the 27 'actor' to help with more modern patterns, i.e. your 26 facade could be an actor, your model view 25 and controller could also be actors that 24 communicate with each other.

Another thing 23 that I've observed is that actor semantics 22 are learnable by most developers and 'safer' than 21 their locked counterparts. This is because 20 they raise the abstraction level and allow 19 you to focus on coordinating access to that 18 data rather than protecting all accesses 17 to the data with locks. As an example, imagine 16 that you have a simple class with a data 15 member. If you choose to place a lock in 14 that class to protect access to that data 13 member then any methods on that class will 12 need to ensure that they are accessing that 11 data member under the lock. This becomes 10 particularly problematic when others (or 9 you) modify the class at a later date, they 8 have to remember to use that lock.

On the other hand 7 if that class becomes an actor and the data 6 member becomes a buffer or port you communicate 5 with via messages, you don't have to remember 4 to take the lock because the semantics are 3 built into the buffer and you will very 2 explicitly know whether you are going to 1 block on that based on the type of the buffer.

-Rick

The usage of Actor is "natural" in 22 at least two cases:

1. When you can decompose your problem in a set of independent tasks.
2. When you can decompose your problem in a set of tasks linked by a clear workflow (ie. dataflow programming).

For instance, if you 21 process complex data using a series of filters, it 20 is easy to use a pipeline of actors where 19 each actor receives data from an upstream 18 actor and sets data to a downstream actor.

Of 17 course, this data-flow must not be linear 16 and if a step is slow in your pipeline, instead 15 you can use a pool of actors doing the same 14 job. Another way of solving the load balancing 13 problems would be to use instead a demand-driven 12 approach organized with a kind of virtual 11 Kanban system.

Of course, you will need synchronization 10 between actors in almost all interesting 9 cases, but contrary to the classic multi-thread 8 approach, this synchronization is really 7 "concrete". You can imagine guys 6 in a factory, imagine possible problems 5 (workers run out of the job to do, upstream 4 operations is too fast and intermediate 3 products need a huge storage place, etc.) By 2 analogy, you can then find a solution more 1 easily.

I am not an actor expert but here is my 19 2 cents when to use actor model: Actor model 18 is not suited for every concurrent application, for 17 instance if you are creating an application 16 which is multi threaded and works in high 15 concurrency actor model is not made to solve 14 the concurrency issue. Where actors really 13 comes into play is when you are creating 12 an event driven application. For instance 11 you have an application and you are tracking 10 what are users clicking in your application 9 realtime. You can use actors to do activities 8 realtime segregated by user, device or anything 7 of your business requirement as actors are 6 stateful. So, for example if some users 5 lies in actors which clicked on shirts you can 4 send them notification of some coupon. Also 3 some applications where actors comes handy 2 are : Finance (Pricing, fraud detection), multiplayer 1 gaming.

Actors are asynchronous and concurrent but 7 does not guarantee message order or time 6 limit as to when the message may be acted 5 upon. Hence atomic transactions cannot be 4 split into Actors.

If the application/task 3 involves no mutable state then Actors are 2 overkill as Actor frameworks go to great 1 lengths to avoid race conditions.