This question looks similar to Should my Scala actors' properties be marked @volatile? but not sure that answer will be the same.
As example, in case when the fork-join dispatcher was configured and actor's state wasn't marked by @volatile, is it guarantied that state of the actor will be propagated through the cache hierarchy from one core (or processor) to another if fork/join worker threads run on different cores (or processors)?
P.S. Is it right that after JSR133 only one write/read operation to/from any volatile variable required to flush cache to main memory and see all preceding non-volatile writings from this thread on other thread that running on other core (or processor)? If yes then it can be answer, because scanning of work queue do some readings and writing from/to volatile variables of FJ task.
No, you shouldn't put volatile on your actor fields. Why?
if an actor makes changes to its internal state while processing a message, and accesses that state while processing another message moments later. It is important to realize that with the actor model you don’t get any guarantee that the same thread will be executing the same actor for different messages.
It's all here: http://doc.akka.io/docs/akka/2.0/general/jmm.html
Regarding your PS, you need to read/write to the same volatile field to get the happens-before guarantee. Read up on "volatile piggybacking"