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
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.
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?
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.
5- Using Futures to access an actor's mutable internal state
It is a potential datarace.
Again thank you so much for any help and all appreciation for the time
spent.
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.
