Remove 'leaps of faith' from our constructors about concurrent-ruby HOT 5 CLOSED

I think the best way is something like that

1. we should define a macro like

def atomic_attribute(name)
  # generates synchronized getter and setter
end 

this macro is different form MRI, JRuby (where we can use your code) and Rubinius

2. in our classes

class XXX

  atomic_attribute :mutex

  def initialize
    self.mutex = Mutex.new
  end
end

from concurrent-ruby.

Wouldn't there be a problem that all the atomic_attributes would share a single lock?

from concurrent-ruby.

The lock will be per-instance and usually we have only few atomic_attr, everything else is guarded by the ruby lock.
My idea is only to take your code and encapsulate it into an handy higher-level idea like the atomic_attr

from concurrent-ruby.

Lets call it volatile_attr since this use-case does not involve CAS operations. Anyway I am not sure about this, we do not have any object using multiple locks in concurrent-ruby, so we do not need volatile_attr at this point. As a user I would also expect from volatile_attr that it won't share a single lock (even though it is per instance), it may lead to unexpected deadlocks. I think adding volatile_attr (or atomic_attr) is another issue and without the JRuby support it would be more costly than just JRuby.reference0(self).synchronized { yield }.

from concurrent-ruby.

will be addressed in #242

from concurrent-ruby.