Re: fast mutexes for 1.8?

At RubyConf 2005 I gave an off-the-wall little talk about the
Monterey Bay Area Research Institute's
work with Ruby in autonomous marine robotic instruments.

A few months into development with Ruby, we uncovered a
serious problem in the the standard Mutex class
implementation in Ruby 1.6/1.8.  It seems appropriate to
mention it here again if folks are considering removing
support for the Thread.critical primitive.

The Mutex class suffers from a race condition when
the mutex is unlocked.  See comments below:

-------------------
  #
  # Releases the lock. Returns +nil+ if ref wasn't locked.
  #
  def unlock
    return unless @locked
    Thread.critical = true
    @locked = false
#the intent here is to wakeup the thread that has been
#waiting on this Mutex the longest....
    begin
      t = @waiting.shift
      t.wakeup if t
    rescue ThreadError
      retry
    end
    Thread.critical = false
#BUT...the Mutex is unlocked at this point!!!
#so Ruby's thread scheduler can (and sometimes does)
#allow another thread to lock this mutex
#before thread t runs
    begin
      t.run if t
    rescue ThreadError
    end
    self
  end

-----------------

Further, the Mutex class is not  "brain friendly", as another poster put
it,
because it fails when a thread that already has the lock tries to lock
it again.
Monitors (as found in Java) handle this "recursive lock" gracefully and so
are, distinct from, and more practical than, Mutexes.

Our application defines its own Recursive Mutex or RMutex class.
RMutexes are used much like Mutexes, but also handle recursive locks.
And, one may optionally include them as a mixin.  It would be very
combersome to write RMutex on top of Ruby's standard
Mutex class.  [If anyone is interested in the RMutex class, let me know.]

I fully appreciate that the existing "Thread.critical" primitive cannot
be supported when native OS threading is used. Some form
of atomic test-and-set should replace it rather than the Mutex class.
Atomic test-and-test cannot be coded in Ruby, but Mutex and
whatever other thread synchronization mechanisms a developer might
dream up could be coded in Ruby were it merely to include
an atomic test-and-set.

I'd be interested in implementing test-and-set if there was a chance
it would be incorporated into the Ruby 1.9 standard libraries.  I envision
a Fixnum-like object that, upon assignment, returns its previous
value, rather than the new one.  Something as simple as:

  a = Atomic.new(0)
  puts(a=7)
  puts a   #this may need to be 'puts a.value' or some such...

Outputs:

  0
  7

Ruby would throw an exception if one attempted to assign an Atomic a
value that not either a Fixnum or another Atomic.

Is anyone already working on something like this?

-- 
 Brent Roman
 Software Engineer 
 mailto:[e-mail]  http://www.mbari.org/~brent