Actor Model description

Actor model

1. Thread problem
The traditional way of offering concurrency in a programming language is by using threads. In this model,
the execution of the program is split up into concurrently running tasks. It is as if the program is being
executed multiple times, the difference being that each of these copies operated on shared memory.
This can lead to a series of hard to debug problems, as can be seen below. The first problem, on the left, is
the lost-update problem. Suppose two processes try to increment the value of a shared object acc. They
both retrieve the value of the object, increment the value and store it back into the shared object. As these
operations are not atomic, it is possible that their execution gets interleaved, leading to an incorrectly
updated value of acc, as shown in the example.
The solution to this problems is the use of locks. Locks provide mutual exclusion, meaning that only one
process can acquire the lock at the same time. By using a locking protocol, making sure the right locks
are acquired before using an object, lost-update problems are avoided. However, locks have their own
share of problems. One of them is the deadlock problem, which is pictured on the right. In this example
two processes try to acquire the same two locks A and B. When both do so, but in a different order, a
deadlock occurs. Both wait on the other to release the lock, which will never happen.
These are just some of the problems that might occur when attempting to use threads and locks.

2. Actor model as solution
In the actor model, each object is an actor. This is an entity that has a mailbox and a behaviour. Messages
can be exchanged between actors, which will be buffered in the mailbox. Upon receiving a message, the
behaviour of the actor is executed, upon which the actor can: send a number of messages to other actors,
create a number of actors and assume new behaviour for the next message to be received.
Of importance in this model is that all communications are performed asynchronously. This implies
that the sender does not wait for a message to be received upon sending it, it immediately continues its
execution. There are no guarantees in which order messages will be received by the recipient, but they
will eventually be delivered.
A second important property is that all communications happen by means of messages: there is no shared
state between actors. If an actor wishes to obtain information about the internal state of another actor, it
will have to use messages to request this information. This allows actors to control access to their state,
avoiding problems like the lost-update problem. Manipulation of the internal state also happens through
messages.


Erlang and Scala have built in support for actor model
.
Link
http://savanne.be/articles/concurrency-in-erlang-scala/