[Ironruby-core] Behavior for Thread.critical=
Shri.Borde at microsoft.com
Mon Jan 12 13:08:06 EST 2009
Thanks for continuing the thread on ruby-core. Let's see how it goes.
There are couple of minor issues with Thread.stop releasing the lock:
* The code will be hard to read as most people probably don't realize that Kernel#stop releases the lock.
* Currently, Kernel#sleep does not release the lock. At the least, it should be consistent with Thread.stop.
* If the programmer wants to release the lock before stopping the thread, its trivial for the programmer to call Thread.critical=false
It's mostly a question of aesthetics and simplicity. The more Thread.critical= can be locked down, the more understandable it will be. But none of these are deal breakers, so I don't feel too strongly.
About reentrancy, I am proposing that it *not* be reentrant (unless an implementation choses to support that behavior). So I think we are on the same page. Reentrancy would normally have been a good thing, but since it looks like an assignment, it would read very weirdly in the case below.
Thread.critical=true # if Thread.critical= was reentrant, this would increment the counter to 2
puts Thread.critical # would be weird if this printed true
Allowing an arbitraty thread to do Thread.critical=false has the same issue as reentrancy. If Thread.critical stayed true after some thread did Thread.critical=false, it would be very misleading. Since the thread cannot actually set Thread.critical to false, it should be an error.
About thread terminating while critical is undefined, some implementations may be able to know if the dying thread still holds the lock, but some may not. Especially in the hosted case where some program is using Ruby as a scripting engine, the hosting app may have created the thread and run some Ruby snippet on it which entered the global critical section, but forgot to leave it. In that case, it would be too burdensome to require that the Ruby implementation deal with this case. Hence, the proposal of leaving this undefined.
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Monday, January 12, 2009 7:55 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Behavior for Thread.critical=
I missed you saying we should nail it first...I already responded on
But I think I agree with everything except for a couple details:
* I think Thread.stop should release the lock as it does now. That's a
pretty minor expectation, and since it's already there (and I know at
least one library depends on it) it should remain.
[Shri Borde] There are couple of issues with allowing this:
Currently, Kernel#sleep does not release the lock. At the least, it should be consistent with Thread.stop.
If the programmer wants to release the lock before
* I'm dubious about the lock being reentrant. In JRuby I've implemented
it using a ReentrantLock, which should count up and count down, but it's
not necessarily a requirement. However I think it would be bad if a
thread could block by setting critical=true when it's already critical.
* I think setting critical=false should only release the lock iff it is
held by the current thread, and do nothing otherwise.
I also agree that a thread terminating while critical is undefined
behavior. But I think most of these questions could be answered by
treating critical= as a globally-shared reentrant mutex.
Shri Borde wrote:
> I asked ruby-core whether descheduling other threads is by spec, but no one other than you replied. Any suggestions on how to nudge others to consider it? If you want to reply to that thread and provide JRuby's vote of confidence for the idea, that might help.
> We should nail the complete behavior before taking it to ruby-core. I have written up a draft at http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx. Please take a look and comment on whether it works for JRuby. We can move it to some wiki if we need to iterate on it...
Ironruby-core mailing list
Ironruby-core at rubyforge.org
More information about the Ironruby-core