Re: fast mutexes for 1.8?

On Mon, 6 Nov 2006, MenTaLguY wrote:

> Many people have been using Thread.critical for locking because Ruby
> 1.8's Mutex is relatively slow.  Since 1.9 will not have
> Thread.critical, I think it would be good to optimize Mutex in 1.8 so
> people can become accustomed to using it today.
>
> Is someone already working on a faster Mutex for 1.8?  If not, I'd be
> interested in doing so.

The main problem with Mutex in 1.8 is that by using push and shift to 
manage the queue of threads instead of unshift and pop, it runs into a 
memory management issue with Array.

Eliminate that, though, and there is precious little left to optimize in 
Mutex.  It's very simple.  It's Sync that's slow because while it uses the 
same simple locking algorithm as Mutex, the unlocking in Sync wakes up 
every waiting thread and lets them compete for a new lock.  This 
amounts to a lot of extra work when there are more than a few waiting 
threads since one of the first threads to be woken up is going to be 
the thread to get the lock anyway.

So, what would you suggest as a performance optimization to Mutex?

I run a modified version of it in IOWA that works around the Array issue, 
but I just don't see how a person could simplify it or optimize it more 
than it already is.


Kirk Haines