Re: fast mutexes for 1.8?

On Sun, 12 Nov 2006, Brent Roman wrote:

> The fast approach is to release the lock, wake all the waiting threads
> and let
> the thread scheduler (more or less randomly) choose which runs first.

This isn't necessarily the fast approach.  This is what Sync does when 
used in exclusive locking mode.  Under Ruby, this is slow, especially if 
one has more than a tiny handful of waiting threads, because one has to 
iterate through that whole list waking each of them, and then each of them 
gets a timeslice to run and try to grab the lock, and almost all are going 
to fail and go back to a waiting state.

It can be a lot of pointless method calling and code execution.

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

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.


Kirk Haines