Thanks for the update :)
Sounds interesting.
/Patrik
ons 10 feb. 2016 kl. 22:04 skrev Mohammed Al-Mahfoudh <
mohammed.mahfo...@gmail.com>:
> Hi Patrick,
>
> Thank you so much for the reply!
>
> That is indeed helpful, I don't know how i missed this reply by almost a
> year, nevertheless that forced me to write some nice Operational Semantics
> for a model based on Akka actors and I kind of shifted my focus from data
> races.
>
> The good thing is that this gave us a whole lot of new directions for
> research based on the actor model, mostly Akka, which is by itself a great
> opportunity and will be of great value for Akka's users/developers. We are
> working hard to publish some good results and helpful tools :), specific to
> Akka but certainly applicable to similar distributed systems model(s).
>
> Best,
> Mo
>
>
> On Sunday, April 26, 2015 at 12:50:18 PM UTC-6, Patrik Nordwall wrote:
>
>> Hi Mo,
>>
>> That is a great list. My comments inline...
>>
> On Fri, Apr 10, 2015 at 10:05 PM, Mohammed Al-Mahfoudh <
>> mohammed...@gmail.com> 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 akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>
>>
>>> 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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
>>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
