From: MenTaLguY <mental@...>
Date: 2006-11-12T07:05:25+09:00
Subject: Re: fast mutexes for 1.8?


--=-7Vmwev2W3i+M3gxHhaSn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

--=-7Vmwev2W3i+M3gxHhaSn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBFVkkjSuZBmZzm14ERAkB7AKCV5ru5RulMNVWgCRT6VdMq+XPsDgCeOiJi
/FZu1J4R+U4xCQeNjONREoA=
=OXf6
-----END PGP SIGNATURE-----

--=-7Vmwev2W3i+M3gxHhaSn--