Hi Mo, That is a great list. My comments inline...
On Fri, Apr 10, 2015 at 10:05 PM, Mohammed Al-Mahfoudh < [email protected]> wrote: > Hi All, > > First of all, great work guys. I love Akka actors. I have been doing my > research in order to target the data races happening in Akka Actors for > quiet some time. > > I have read through all the documentation for the scala version. I got a > list of data race conditions from the "docs" compiled but when it is time > to code it (been trying for a week now), I am not able to actually > experience these data races! although they are still mentioned in the > documentation. > > If these data races are avoided e.g. by doing an implicit copy of a > referenced object on a call of (!/tell) can some one please help me > identify which is still valid and show me (may be simple two-actors code) > exhibiting that data race in order to try it my self? > > > Here is the list of the data races: > > 1- Sending a message that encapsulates a mutable state > e.g.: > > #+BEGIN_SRC > scala > > class MyActor extends Actor > { > > var state = > ... > > def receive = > { > > case _ > => > > > //Wrongs > > > > // Very bad, shared mutable > state, > > // will break your application in weird > ways > > Future { state = NewState > } > > anotherActor ? message onSuccess { r => state = r > } > > > > // Very bad, "sender" changes for every > message, > > // shared mutable state > bug > > Future { expensiveCalculation(sender()) > } > > > > > //Rights > > > > // Completely safe, "self" is OK to close > over > > // and it's an ActorRef, which is > thread-safe > > Future { expensiveCalculation() } onComplete { f => self ! > f.value$ > > > > // Completely safe, we close over a fixed > value > > // and it's an ActorRef, which is > thread-safe > > val currentSender = > sender() > > Future { expensiveCalculation(currentSender) > } > > > } > > > } > > > #+END_SRC > > Think for example of what happens if the shared state is a counter and you try to increment it from several threads concurrently. MyActor must receive another message for the sender() to change. It could be null also. > 2- Using a props factory method > #+BEGIN_SRC > Scala > > val props2 = Props(new ActorWithArgs("arg")) // careful, see > below > > > #+END_SRC > > The best use of the second varian't should be OUTSIDE of an > actor. Things that can go wrong: > - Race conditions > - Non-serializeability > - The need to implement anonymous actor classes on the spot > > *Reason*: it closes over a class. > *NOTE*: Future implementation will use macros to avoid these > headaches. > The actor is created in a separate thread, e.g. problem if the Props creator is accessing mutable state in an enclosing actor instance (e.g. sender()). > > 3- Declaring an Actor inside another actor > It breaks actor encapsulation (possibly makes a datarace). > > _is it this situation?_: the inner actor re-uses the a field of > enclosing actor after there is some instances of the first > scheduled for execution. (i.e. name and scope clash) > > _or this one?_: the inner actor re-initializes a field of > enclosing actor after there is some instances of the first > scheduled for execution. > > Or something completely different? > It is easy to do mistakes by accessing mutable state of the outer actor from the inner actor. > > 4- Passing an actor's "this" reference into "Props" > Use "self" to get an actor's self reference. Same goes for > TypedActors. > > *Reason*: "self" is a method so it is a call back, while "this" is > a specific actor object "reference" that can be still alive or not > anymore. > Creation of another actor via Props is running in a separate thread, as mentioned above. Therefore that should not access things in the other actor's instance ("this"). > 5- Using Futures to access an actor's mutable internal state > It is a potential datarace. > > Similar as already discussed. > > Again thank you so much for any help and all appreciation for the time > spent. > I hope that will guide you in the right direction. /Patrik > > All the best, > Mo > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
