« Return to Thread: [ruby-core:20999] Supporting Thread.critical=with native threads
[ruby-core:21011] Re: Supporting Thread.critical=with native threads
by Shri Borde
::
Rate this Message:
Yes, Thread#kill and Thread#raise can be implemented in IronRuby by using System.Threading.Thread.Abort (http://msdn.microsoft.com/en-us/library/system.threading.thread.abort.aspx). It is fragile (like you say, its impossible to support such operations reliably on native threads), and can be deferred indefinitely under some circumstances. So I think we ideally need to use both Thread.Abort and checkpoints.
About Thread.critical, you said:
> 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
It would seem such code will not work even with MRI. If thread 1 sets Thread.critical=true and starts initializing the instance variable, and if thread 2 is accessing the instance variable without setting Thread.critical=true, then couldn't thread 2 run into a problem even if its not scheduled, since it could be anywhere in the middle of accessing the instance variable? To be fully correct, wouldn't thread 2 have to set Thread.critical=true, even on MRI?
By the way, what is the level of atomicity supported by MRI? For example, CPython uses the global interpreter lock (GIL) for each bytecode. However, since MRI does not compile to bytecode, is the AST nodes the correct level of atomicity?
-----Original Message-----
From: Charles.O.Nutter@... [mailto:Charles.O.Nutter@...] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, December 30, 2008 3:19 PM
To: ruby-core@...
Cc: Jim Deville
Subject: [ruby-core:21000] Re: Supporting Thread.critical=with native threads
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
About Thread.critical, you said:
> 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
It would seem such code will not work even with MRI. If thread 1 sets Thread.critical=true and starts initializing the instance variable, and if thread 2 is accessing the instance variable without setting Thread.critical=true, then couldn't thread 2 run into a problem even if its not scheduled, since it could be anywhere in the middle of accessing the instance variable? To be fully correct, wouldn't thread 2 have to set Thread.critical=true, even on MRI?
By the way, what is the level of atomicity supported by MRI? For example, CPython uses the global interpreter lock (GIL) for each bytecode. However, since MRI does not compile to bytecode, is the AST nodes the correct level of atomicity?
-----Original Message-----
From: Charles.O.Nutter@... [mailto:Charles.O.Nutter@...] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, December 30, 2008 3:19 PM
To: ruby-core@...
Cc: Jim Deville
Subject: [ruby-core:21000] Re: Supporting Thread.critical=with native threads
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
« Return to Thread: [ruby-core:20999] Supporting Thread.critical=with native threads
| Free embeddable forum powered by Nabble | Forum Help |
