Re: fast mutexes for 1.8?

On Wed, 2006-11-08 at 16:47 +0900, Brent Roman wrote:
> #BUT...the Mutex is unlocked at this point!!!
> #so Ruby's thread scheduler can (and sometimes does)
> #allow another thread to lock this mutex
> #before thread t runs

In other words, a non-waiting thread could potentially "jump the queue"
and acquire the lock before a waiting thread.

I've addressed this in my own Mutex implementation and am looking into
what might need to be done for condition variables along similar lines.

> I fully appreciate that the existing "Thread.critical" primitive cannot
> be supported when native OS threading is used. Some form
> of atomic test-and-set should replace it rather than the Mutex class.
> Atomic test-and-test cannot be coded in Ruby, but Mutex and
> whatever other thread synchronization mechanisms a developer might
> dream up could be coded in Ruby were it merely to include
> an atomic test-and-set.

It's worth pointing out that a locking primitive implemented atop a
"native" mutex and condition variable(s) would likely be faster than one
implemented atop an atomic test-and-set operation in Ruby, because in
the latter case you'd need to incur a lot of method calls to do all your
wait queue management in Ruby (one of the reasons the current Mutex is
so slow).

-mental