actor handling multiple messages at the same time - scala

Question

I know one of the advantages of the actor model is that by handling only one message at a time, concurrency issues are simplified. But it seems to me that my actor is handling multiple messages. In pseudo code I have
var status = 0
def receive = {
case DoSomething =>
val dest = sender()
status = 0
for {
otherActor <- resolveOtherActor("/user/OtherActor")
} yield {
for {
res <- {status = 1
otherActor ? doSomething1
}
res <- {status = 2
otherActor ? doSomething2
}
} yield {
dest ! status
}
}
case GetStatus => sender() ! status
}
If I send a DoSomething messages to this actor, and then immediately send GetStatus to this actor repeatedly, I will see status 0, 1 and 2 coming back in sequence. If the actor model only handled one message at a time, I would only ever see status 2 being returned, since I wouldn't have access to the intermediate status.
It seems that locks are still necessary with the actor pattern. What am I missing?

Answer 1

All bets are off when you close over an actor's mutable state and expose it to other threads, which is what your code is doing when it mutates status inside a (nested) Future. The Akka documentation clearly warns against this.
An actor does process one message at a time:
var status = 0
def receive = {
case IncrementStatus =>
status += 1
case GetStatus =>
val s = status
sender ! s
}
Sending an IncrementStatus, another IncrementStatus, then a GetStatus message from the same sender to the above actor will cause that sender to receive a 2.
However, trying to do the same thing with Futures does not guarantee the same outcome, because a Future is completed asynchronously. For example:
object NumService {
// calculates arg + 1 in the future
def addOne(arg: Int): Future[Int] = {
Future { arg + 1 }
}
}
class MyActor extends Actor {
var status = 0
def receive = {
case IncrementStatusInFuture =>
val s = status
NumService.addOne(s)
.map(UpdateStatus(_))
.pipeTo(self)
case UpdateStatus(num) =>
status = num
case GetStatus =>
val s = status
sender ! s
}
}
We map the Future to create a Future[UpdateStatus], then pipe to the actor itself the result of that Future.
If we send an IncrementStatusInFuture, another IncrementStatusInFuture, then a GetStatus message to MyActor from the same sender, we cannot guarantee that the sender will receive a 2. The actor processes those three messages in order, but one or both of the calls to NumService.addOne might not have completed by the time the actor processes the GetStatus message. This nondeterministic behavior is a characteristic of a Future; it is not a violation of the actor principle of one-message-at-a-time processing.