Re: fast mutexes for 1.8?

On Mon, 2006-11-06 at 23:17 +0900, Hugh Sasse wrote:
> 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.
> 
> Agreed.  But ruby-1.8.5/lib/thread.rb contains the definition of Mutex
> and it uses Thread.critical extensively....

That's okay for 1.8.  1.9 (YARV) will have to have its own
implementation anyway.

> This has puzzled me for a while, but I don't know enough about this. It
> seems to me that this means two instances of Mutex will interact horribly
> even when the intent of the programmer is that they are independent.
> I couldn't think of a better way to do it though, so I mean no disrepect
> by this observation.

Thread.critical (or rb_thread_critical, if you're coming from C-land) is
the only way to do things atomically in Ruby.  Mutex just dips into a
critical section briefly to protect the owner and wait list variables
when it works with them; it doesn't hold on to Thread.critical for the
duration of the lock.

-mental