From: Brent Roman <brent@...>
Date: 2009-01-15T13:58:12+09:00
Subject: [ruby-core:21359] Re: Supporting Thread.critical=with native threads


Shri & Charlie,

I just had a look at the proposed spec for Thread.critical= at
 
http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx

When Ruby 1.6.8 first appeared, all the thread locking primitives had
Thread.critical=
at their core.  It was the only thread locking mechanism available.

No one is claiming that it is good or modern.  The only reason to keep
supporting it
is to allow old Ruby scripts to run in newer implementations.  

To that end, I'd like to point out that:
  1)  Thread.critical= is not a block construct.  Talking about it being
reentrant or not makes no sense.
       It is a global attribute, atomically set true or false.
         --> Thread.exclusive {} is a block construct based on
Thread.critical.  Is that the confusion?

  2)  If a thread executes Thread.critical=true when it is already true,
absolutely nothing changes.
 
  3)  Thread.critical=false exits the critical section, regardless of how
many times it had been been redundantly set true.

  4)  Thread.critical=false when it is already false does absolutely
nothing.

  5)  If a thread dies while Thread.critical=true, it remains set.  It does
not throw an exception.

  6)  Thread.stop sets Thread.critical=false and blocks the current thread
in one, atomic operation.

There should be no wriggle room in the spec about this.  The existing
behavior may not be optimal, but it is simple and well established.  Old
code depends on it, warts and all.  New code should avoid the use the
Thread.critical entirely.

For native threaded implementations, all of this can, and probably should,
be implemented with a single, non-reentrant mutex.  Thread.critical=true
when it was false would lock the global mutex and may block waiting for it. 
Thread.critical=false when it was true would unlock it.

I think this approach is straightforward, allows native threaded
interpreters to avoid expensive checkpointing and maintains very good
compatibility with existing Ruby scripts.  I would suggest that JRuby keep
its existing checkpointing available as a run-time option for maximum
compatibility, analogous to its support of ObjectSpace.  Thus, JRuby could
continue to support those few scripts that do depend on the fact that, in
MRI and other green threaded implementations, Thread.critical=true can be
used to keep all other threads from running.

- brent

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