From: khaines@...
Date: 2006-11-07T02:50:55+09:00
Subject: Re: fast mutexes for 1.8?

On Tue, 7 Nov 2006, MenTaLguY wrote:

> On Mon, 2006-11-06 at 23:21 +0900, khaines@enigo.com wrote:
>> So, what would you suggest as a performance optimization to Mutex?
>
> Principally, pushing the whole thing into C and using a better data
> structure than a dynamically allocated C array of VALUEs (what underlies
> Array) for the wait queue.
>
> That way, we can eliminate a whole slew of Ruby method calls and
> variable lookups, as well as making all the important wait queue
> operations O(1).  That complexity thing will probably matter less than
> it should, since wait queues aren't normally that long, but eliminating
> all those method calls should be a big win.
.
.
.
> I'm reasonably confident that I can get the no-contention case for
> Mutex#synchronize down to somewhere in-between "noop method" and
> "open-coded critical".  At that point, Mutex#synchronize becomes the
> most appealing option, making one less bump on the road when porting
> code from 1.8 to 1.9.

Given that IOWA already uses an internal version of Mutex, I'm game for 
some further work on optimizing Mutex in the ways you describe.


Kirk Haines