« Return to Thread: [ruby-core:20999] Supporting Thread.critical=with native threads
[ruby-core:21000] Re: Supporting Thread.critical=with native threads
by Charles Oliver Nutter-2
::
Rate this Message:
Shri Borde wrote:
> Thread.critical= is supposed to not schedule any other thread, in
> addition to guaranteeing that only one thread is ever in the block with
> Thread.critical==true. This is easier to support with green threads.
>
> With native threads, it is harder to do. I am working on IronRuby, and
> have some questions:
I'll go one further...with native threads (running in parallel) it's
*impossible* to do reliably.
> 1. Should it be by spec that other threads are not allowed to be
> scheduled? Thread#inspect for the other threads actually says “run”, not
> “sleep”.
>
> 2. How would you test that the other threads are not scheduled. It can
> be done by having the other threads increment some class variable, and
> by checking that its value does not change. So this is mostly a
> rhetorical question.
>
> 3. Given that implementations with native threads cannot support this
> perfectly, how many apps would actually be affected? The few gems I have
> looked at only need that Thread.critical=true only behave like a
> critical section. The apps will work even if the other threads are
> scheduled, as long the other threads block when they themselves try to
> set Thread.critical=true. According to
> http://www.megasolutions.net/ruby/basic-threading-question_can-ruby-use-real-threads_-64225.aspx,
> JRuby supports this by having every thread periodically do a checkpoint
> to see if it should suspend itself. It seems that most apps would
> continue working if there was only one checkpoint,in Thread.critical=.
Scripts that use critical= tend to expect that they're guaranteeing more
than just the code in the critical section. For example, if they're
initializing an instance variable they expect nobody else will access it
during initialization. There's probably many cases that just want a
critical section, but others that expect more.
The bottom line, however, is that critical= is *bad*, and that's why it
went away in 1.9. Any code out there that uses it should *not* use it,
and since it's impossible to support unless your implementation does not
support parallel execution of threads, I'd also argue it shouldn't ever
be expected to work.
We have it working in JRuby, and would certainly rather remove it.
However we also need thread checkpoints to support Thread#kill and
Thread#raise, so it wouldn't eliminate checkpointing entirely. I believe
.NET allows threads to be killed (wrongly) so you may not have this problem.
- Charlie
> Thread.critical= is supposed to not schedule any other thread, in
> addition to guaranteeing that only one thread is ever in the block with
> Thread.critical==true. This is easier to support with green threads.
>
> With native threads, it is harder to do. I am working on IronRuby, and
> have some questions:
I'll go one further...with native threads (running in parallel) it's
*impossible* to do reliably.
> 1. Should it be by spec that other threads are not allowed to be
> scheduled? Thread#inspect for the other threads actually says “run”, not
> “sleep”.
>
> 2. How would you test that the other threads are not scheduled. It can
> be done by having the other threads increment some class variable, and
> by checking that its value does not change. So this is mostly a
> rhetorical question.
>
> 3. Given that implementations with native threads cannot support this
> perfectly, how many apps would actually be affected? The few gems I have
> looked at only need that Thread.critical=true only behave like a
> critical section. The apps will work even if the other threads are
> scheduled, as long the other threads block when they themselves try to
> set Thread.critical=true. According to
> http://www.megasolutions.net/ruby/basic-threading-question_can-ruby-use-real-threads_-64225.aspx,
> JRuby supports this by having every thread periodically do a checkpoint
> to see if it should suspend itself. It seems that most apps would
> continue working if there was only one checkpoint,in Thread.critical=.
Scripts that use critical= tend to expect that they're guaranteeing more
than just the code in the critical section. For example, if they're
initializing an instance variable they expect nobody else will access it
during initialization. There's probably many cases that just want a
critical section, but others that expect more.
The bottom line, however, is that critical= is *bad*, and that's why it
went away in 1.9. Any code out there that uses it should *not* use it,
and since it's impossible to support unless your implementation does not
support parallel execution of threads, I'd also argue it shouldn't ever
be expected to work.
We have it working in JRuby, and would certainly rather remove it.
However we also need thread checkpoints to support Thread#kill and
Thread#raise, so it wouldn't eliminate checkpointing entirely. I believe
.NET allows threads to be killed (wrongly) so you may not have this problem.
- Charlie
« Return to Thread: [ruby-core:20999] Supporting Thread.critical=with native threads
| Free embeddable forum powered by Nabble | Forum Help |
