From: Brent Roman <brent@...>
Date: 2009-01-19T18:28:15+09:00
Subject: [ruby-core:21432] Re: Supporting Thread.critical=with native threads


Charlie & Shri,

Ruby 1.9 doesn't support Thread.critical=  However, when I last looked
(about a year ago) it still had a "Giant VM Lock"  to prevent multiple Ruby
threads from running in parallel.  MRI struck this compromise because it
must to be able to run existing 'C' extensions unmodified.   In this
threading environment it is quite easy to add this support for
Thread.critical=.  I'm guessing the decision to delete Thread.critical= was
to open the door for parallel threading in Ruby 2.x sometime in the future.

Ruby 1.9 *does* support Thread.exclusive {} by mapping this onto a global
Mutex.  If you don't care about backward compatibility, then why do you need
to blaze your own trail here? 
Why not do exactly as v1.9 has already done?

The "cross-impl critical= spec" is not supported by any existing
implementation.

Thread.critical is a flag that affects thread scheduling.  It is not a
Mutex.
It commonly gets set when it is already true and cleared when it is already
false.
Both these operations are NOPs in the current implementation!
One doesn't have to get deep into Threading Zen to see that the spec you
have posted will cause most existing code that uses Thread.critical= in any
way 
other than as a means of implementing a simple Mutex to fail. 

The only way to support the existing Thread.critical= behavior in a
meaningful way is in the context of a reduced performance threading model
where only one Ruby thread runs at a time.  If there were another way, I
think v1.9 would have retained it.

You've got two choices, as I see it.  Remove Thread.critical , or maintain
an optional thread scheduling mode with a Giant VM Lock to ensure that only
one thread runs at a time for backward compatibility with v1.8 and before.

Everything you've posted about the "vigorous checkpointing" JRuby does to
support Thread.critical= indicates to me that even this valiant effort fails
to implement Thread.critical in a parallel threading VM.  So, yes, in a
nutshell, "It is better to make a hard break".  Drop support for
Thread.critical= unless you intend to support the threading environment on
which it depends.

- brent

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