when is actor not appropriate?

Question

I use actors whenever I need to run two threads concurrently. I don't ever use threads explicitly.

someone told me that actors are quite heavy and it is not always a good idea to use them.

• What are the right scenarios to use actors and when not to use them?

• Some of my actors just have a loop but no react. Is this a good practice?

[EDIT]

• Is it bad practice to use Thread.sleep inside the loop of an Actor?

Answer 1

Actors provide a distributed asynchronous algorithm with message passing model of computation, and is most adequate for tasks that fit that model.

Scala's actors can share memory, making it adequate for algorithms that rely on memory sharing, but not particularly so because you give up actor's main advantages. On the other hand, there's no particular disadvantage either.

See Distributed Computing on the wikipedia for more information.

There are two main classes of tasks that are not particularly good fit:

• Tasks that depend heavily on synchronism

  This is not really related to locks, or waiting for something before beginning something else. The main characteristic of synchronous systems is a heavy dependency on temporal ordering of tasks.

  For example, if you need to know which task finished first, then actors lack of guarantee of ordering of messages make them a bad fit.

• Tasks that are inherently data parallel

  This is the situation where the same computation is performed over different chunks of data, with no dependency between them.

  The "map" part of map-reduce algorithms fit this case.

  While actors can do this, the same thing can be done with fork/join setups with less overhead. Scala 2.9 will have parallel collections targeted at this type of task.

Answer 2

Well, it is easy to assume that just because two pieces of code are running is different threads as follows:

new Thread(work1).start()
new Thread(work2).start()

That they must be running concurrently. Of course, this is not necessarily the case, and will be determined, largely, by the OS. So, it is possible that by splitting a piece of sequential work into large numbers of parallel sub-computations, all you are doing is creating an overhead of object creation and context-switching.

However, the ForkJoin framework, which sits underneath Scala's actor system is supposed to appropriately-size its internal pool of threads. This removes the unnecessary context-switching overhead, leaving only the overhead of any (possibly unnecessary) object/creation