From: Brent Roman <brent@...>
Date: 2009-01-17T14:20:57+09:00
Subject: [ruby-core:21387] Re: Supporting Thread.critical=with native threads


Hi Shri,

See comments below--->


Shri Borde wrote:
> 
> OK. I understand that MRI cannot make breaking changes lightly (though I
> do think the API is hard to use the way it is currently speced). We will
> treat this as an incompatibility in IronRuby and deal with it the best we
> can.
> 
> --->  What, precisely, will be the nature of the incompatibility?
>         Do you intend to implement your proposed redefinition of
> Thread.critical=, or to mimic the all the existing Thread.critical=
> behaviors except for descheduling?
> 
> FWIW, Thread.pass and Kernel#sleep do not set Thread.critical to false.
> However, they do cause other threads to be scheduled. 
> 
> --> This isn't news to me.  Have a look at my post titled "Thread
> misbehavior" dated 1/15/05.
>       The patched Ruby 1.6.8 that we deploy in embedded systems sets
> Thread.critical=false whenever a the thread scheduler is invoked.  Our
> Kernel#doze extension clears Thread.critical immediately before blocking. 
> 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.  Changing this
> particular aspect of Thread.critical probably is a good idea.  The other
> changes you proposed seem designed to make Thread.critical work like a
> Mutex, which it, unfortunately, is not.
> 
> 
> So in your scenario, when you hit a breakpoint, if you call some utility
> code that happens to do Thread.pass, it will "restart the world" which you
> will not be expecting.
> 
> --->  Why would one run a utility that does Thread.pass to examine system
> state for debugging?
> 
> 
> Also, if you create a new thread expecting no one to see its uninitialized
> state, I think this is fragile design that will be prone to bugs. If any
> shared data is accessed from two threads, it should be done only if the
> threads have set Thread.critical=true (ie. use Thread.critical as a mutex
> without relying on descheduling of other threads).
> 
> I would be curious to see real-world patterns where shared data is
> accessed safely from two threads, and which relied on descheduling of
> other threads - to see if it was indeed done safely. (I don't mean to
> suggest that your particular code has bugs but ...) I think many people
> who try to use this pattern will end up with latent bugs, and I would like
> to see if this is the case or not.
> 
> --->  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.
> 
> 

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?
Or, support Thread.critical only in an optional lower-performing
"compatibility mode" where only one thread is allowed to run at a time.

- brent

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20999--Supporting-Thread.critical%3Dwith-native-threads-tp21224464p21513297.html
Sent from the ruby-core mailing list archive at Nabble.com.