Dereferenceable mutex race condition

[mighe]

Dereferenceable module lazy initializes its mutex without any other lock, opening the possibility of a race condition and visibility issues.
To fix this, we have to manually init the mutex in every class that includes it.
I think this solution is not very clean and is a little error prone, but AFAIK there isn't a better way to initialize module instance variables... maybe we can change the mutex method to raise an exception if the var is not set.

In this commit set_deref_options has been refactored a bit removing unnecessary code

[jdantonio]

I've only glanced at the code briefly, but I think we may be able to implement included in Dereferenceable to eager load the Mutex. http://ruby-doc.org/core-1.9.3/Module.html#method-i-included

Thoughts?

[mighe]

Module#included takes as parameter the class that includes it, so we can "do something'" at class level; unfortunately in this case we have to work at instance level.
Scala solves this problem in a very elegant way, providing module (Trait) constructors that are missing in Ruby

Maybe an alternative could be to transform Dereferenceable module into it a normal class, in that way we can use object composition and not inheritance (like I'd do in Java, for example): we'll lose something in elegance terms, but our code can be a bit more thread safe "by design"

[kwando]

I like the explicit "unelegant" approach. Thread safety is complex enough without metamagic =)

[jdantonio]

@mighe Thank you for the updates you have made. Are you working on more? I would like to release an updated version of the gem so that your updates are available to the public but I'll hold off if you have other updates pending.

[mighe]

Hi Jerry, I don't have any other pending updates.
You can release the gem as is, I'm going to implement some changes but I could not find time yet :-(
I hope I can do them as soon as possibile.