The Actor Model originated in 1973 and allows easy description of stateful objects that execute concurrently with each other. They pass messages and, fundamentally, these messages are delivered without the sender ever waiting for the receivet to acknowledge receipt (i.e. the messages are exchanged asynchronously).
PROC actor (CHAN? OF ANY in)
WHILE TRUE
SEQ
:
No control over aliasing
It is easy to send mutable data structures, such as collections, in messages between actors. This is a fundamentally dangerous thing to do because both sender and receiver can make unguarded modifications to the shared state, i.e. suffer from race conditions. Akka does nothing to control this risk other than advise developers of the need to avoid it.
No control over race conditions
Akka has an easily accessible scheduler for running additional tasks, such as future timeout operations. It is easy to refer to a mutable variable by mistake in such an action, leading to indeterminate behaviour.
If asynchronous APIs are used to obtain values at some future time, the actor state may be different when the future closure finishes compare to when it starts. This kind of race condition causes errors that are very hard to diagnose. The solution is to make local value copies of the current state before starting the future, then only refer to these, but this is just a kludge.
comments powered by Disqus