Remove 'leaps of faith' from our constructors

[pitr-ch]

As discussed in #102, assigning ivars in #initialize method does not guarantee their visibility. Following synchronization pattern should be used under JRuby.

  require 'jruby'
  def synchronize
    JRuby.reference0(self).synchronized { yield }
  end

  def initialize
    synchronize do
      # body of the constructor ...
    end
  end

  def a_method
    synchronize do
      # body of a_method ...
    end
  end

[mighe]

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

[pitr-ch]

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

[mighe]

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

[pitr-ch]

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 }.