From: Shri Borde <Shri.Borde@...>
Date: 2009-01-18T17:14:21+09:00
Subject: [ruby-core:21401] Re: Supporting Thread.critical=with native threads


> What, precisely, will be the nature of the incompatibility?

I am not sure where we will finally land as that will probably depend on user feedback, but we will need a note in some doc to point out that the semantics are not exactly the same as MRI. Currently, I have it implemented as a global mutex.

> I agree that, without these changes, the current behavior is
> non-deterministic, as a thread can suddenly become "critical" at any
> random moment.  For now, all one can say is that threads in critical
> sections should not invoke Thread.pass or Kernel#sleep.

Yup, this aspect is impossible to support without green threads.

> --->  This code was written five years ago and is in hard use every day.
> The Mutex pattern is safe, but  well designed Mutexless patterns perform
> much better in practice.  In any case, there's no point in arguing whether
> such code is good or bad.  It simply is.

I just wanted a canonical example of correct Mutexless code which relied on descheduling of Thread.critical=. Its easier to think about the scenario with a real example in mind. As mentioned in http://blogs.msdn.com/vancem/archive/2006/03/29/564854.aspx, one should be suspicious of lock-free code, and I have seen examples of lock-free production code which actually had latent bugs. That is not to say that lock-free code cannot be written. I just wanted to see a pattern in Ruby.

> You might want to consider dropping support for Thread.critical= from native
> threaded Ruby interpreters.
> This is what MRI did with their version 1.9.  Why not make a clean break?

I was not aware of this. I just tried 1.9 and the method is indeed gone! Note that the proposed change of the semantics I and Charles are suggesting were targeting some future version of MRI so that IronRuby and JRuby could get more compliant in the future. I did not expect 1.8.6 to be changed. With the method gone in 1.9, I couldn't have asked for a better resolution.