Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should my Akka actors' properties be marked @volatile?

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.

like image 595
Andriy Plokhotnyuk Avatar asked Apr 15 '12 20:04

Andriy Plokhotnyuk


People also ask

Is Akka actor thread safe?

Actors are 'Treadsafe'. The Actor System (AKKA), provides each actor with its own 'light-weight thread'. Meaning that this is not a tread, but the AKKA system will give the impression that an Actor is always running in it's own thread to the developer.

How do actors work in Akka?

What is an Actor in Akka? An actor is essentially nothing more than an object that receives messages and takes actions to handle them. It is decoupled from the source of the message and its only responsibility is to properly recognize the type of message it has received and take action accordingly.

Why Akka?

Akka makes it possible to build software systems with reliability and high performance, without sacrificing developer joy and productivity. In short, Akka is open source middleware for building highly concurrent, distributed and fault-tolerant systems on the JVM.


1 Answers

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"

like image 117
Viktor Klang Avatar answered Oct 24 '22 00:10

Viktor Klang