--fNbDVMXOpFUdzBPhK3i
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

--fNbDVMXOpFUdzBPhK3i
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)

iD8DBQBFT2ihSuZBmZzm14ERAl/FAKC47GyCTHzhB29X2+J/XBoci4lq+QCdEaaM
CtWzbs2LICRhPmjcJBF2U14eF
-----END PGP SIGNATURE-----

--fNbDVMXOpFUdzBPhK3i--