Re: fast mutexes for 1.8?

>
>FWIW, I don't think there's a strong reason to limit it to Fixnums; you
>probably had atomic_t in mind, but that won't be an issue for e.g. JRuby
>and probably other implementations.  May as well let Atomic store a
>reference to any Object.
>
>-mental
>
Yes, I agree that there is no reason to limit the Atomic class to Fixnums.
The only important behavior is that assignment be atomic and that it
return the previous value, rather than the new one.


>> The fair approach is to pass the lock from the thread releasing it,
>> directly to the thread that had been waiting the longest for the it.
>> It appears that both approaches have been tried at various times
>> in the history Linux threading library (in glibc).
>
> Kirk Haines wrote:
>
> This is essentially what the current Mutex class does.  Waiting
> threads go into an array that is used as a queue.  As new threads go
> into one end of the queue, threads are removed from the other end.
>

This is what the Mutex class *proports* to do.  However, if you look
closely at the code
you will see that the lock is released before the next thread is
started.  As I (and
others) have noted, this gives a third thread an opportunity to "jump
the queue" by
acquiring the lock before the intended thread acquires it.  I've had
multi-threaded
code that relies on "fair" queuing fail (very intermittently) with the
stock Ruby
Mutexes due this queue jumping.  It's real and very difficult to debug.
That why we now have our own varient of the Mutex class that remains "fair"
by altering the lock's owner and starting the recipient thread without ever
releasing the lock, thereby executing a controlled handoff rather than a
free-for-all.

-- 

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