Re: fast mutexes for 1.8?

On Tue, 7 Nov 2006, Eric Hodel wrote:

> On Nov 6, 2006, at 5:57 AM, 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.
> 
> As has been discussed further down in this thread, there isn't much to do to
> make Mutex faster.  The only remaining thing is to avoid Mutex#synchronize
> when you need to be really fast.  The block invocation overhead huge.  Instead

It is really only a lock; begin; yield; ensure; unlock; end;
Blocks are pretty central to Ruby.  My reading of eval.c suggests
that it might be possible to optimise
rb_yield_0(val,self,klass,flags,value) for the cases where self,
klass and flags are known to be 0, as they are when rb_yield is
called.  This would result in some code duplication, however.  Has
anyone explored this?  I'm just thinking that given the amount of
grief Ruby gets for its perceived low speed, that it might be worth
examining.  I'm not aware that compilers can optimize this sort of
thing away.

> use #lock, #unlock and ensure.
> 
        Hugh