From: Charles Oliver Nutter <charles.nutter@...>
Date: 2009-01-13T00:34:26+09:00
Subject: Re: Binding.of_caller examples don't work.

Ken Bloom wrote:
> Which reminds me of another question I had. You were discussing somewhere 
> else how Thread.critical works in JRuby. Does Thread.critical / 
> Thread.exclusive in JRuby protect other threads against changes to the 
> core class methods? Can I run Thread.critical=true , dramatically 
> redefine operators on the core classes, redefine the operators back  
> their original implementations, run Thread.critical=false, and expect 
> that no other JRuby thread can get in and be broken becuase I've 
> dramatically gutted the core classes?

You could up until about a week ago, when I proactively modified 
critical= to just be a reentrant global lock. So basically..

Before:
* critical= causes the current thread to be the only thread running
* ...except on JRuby where threads run in parallel and have to reach a 
checkpoint before they stop
* ...or if code you call from within a critical section itself spins up 
threads

After:

* critical= acquires or releases a lock on a global mutex
* threads that don't have critical sections continue running
* threads that try to acquire the lock while another thread has it block

This was actually proposed by Shri Borde of IronRuby and blogged here:

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

She (he?) proposes that almost all current uses of critical= intend to 
simply delimit a critical section of code, and so a single global mutex 
is sufficient for those cases. And in light of the fact that native 
calls and parallel-threaded impls can't be guaranteed to deschedule 
other threads, I think this is a much more concrete and reasonable 
definition. So I agreed, said so on a critical-related ruby-core thread, 
and went ahead with the change. Nothing has broken so far :)

For your case, I think your best bet is to either make those changes 
before other threads start running or just accept that some of them 
won't see your changes all at once. I believe what you want to do may 
work on MRI, since it doesn't actually run threads in parallel and 
critical= stops it from scheduling new ones on its own.

But also note that critical= is gone in 1.9, so you should not use it 
anyway. Use a Mutex whenever possible...it's quick, easy, and safe.

- Charlie