[ruby-core:21362] Re: Supporting Thread.critical=with native threads

One of the points in the spec is that with native threads, there is no way =
to guarantee that all other threads stop when Thread.critical=3Dtrue is cal=
led. If you want to allow Threads to block waiting for a global mutex, you =
risk deadlocks, which isn't an acceptable alternative.

I thought that either Charlie or Shri had looked and not currently found a =
piece of code expecting Thread.critical to unscheduled other threads. Do yo=
u have a counter example?

JD

-----Original Message-----
From: Brent Roman [mailto:[e-mail]]
Sent: Wednesday, January 14, 2009 8:58 PM
To: [e-mail]
Subject: [ruby-core:21359] Re: Supporting Thread.critical=3Dwith native thr=
eads


Shri & Charlie,

I just had a look at the proposed spec for Thread.critical=3D at

http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thr=
ead-critical.aspx

When Ruby 1.6.8 first appeared, all the thread locking primitives had
Thread.critical=3D
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=3D 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=3Dtrue when it is already true,
absolutely nothing changes.

  3)  Thread.critical=3Dfalse exits the critical section, regardless of how
many times it had been been redundantly set true.

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

  5)  If a thread dies while Thread.critical=3Dtrue, it remains set.  It do=
es
not throw an exception.

  6)  Thread.stop sets Thread.critical=3Dfalse and blocks the current threa=
d
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=3Dtrue
when it was false would lock the global mutex and may block waiting for it.
Thread.critical=3Dfalse 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=3Dtrue can be
used to keep all other threads from running.

- brent

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