I'm starting come around to Shri's idea of critical= being represented 
as simply a global lock. Shri makes a very strong case that the 
descheduling behavior of critical is a side effect that almost nobody 
depends on. I'd go further and say that nobody *should* depend on it, 
since on e.g JRuby there's no guarantee when or if the other threads 
will completely deschedule.

Representing critical= as a global reentrant mutex would also reduce the 
overhead parallel-threaded impls deal with to constantly checkpoint, and 
would codify a very clear and specific meaning for critical sections. It 
would not be a recommended way to criticalize a block of code, since it 
could bottleneck if several threads try to criticalize. But it would at 
least be more reasonable to support on parallel-threaded impls than what 
we have today.

Interestingly enough, a global critical lock also is compatible with 
what 1.8 does right now, since 1.8's total descheduling of other threads 
is a superset of global lock behavior. The only bits that are fuzzy 
would be threads explicitly scheduled or spun up during a critical 
section, and we'd need to discuss those.

Thoughts? I almost want to just make this change in JRuby right now, 
since it's so much cleaner.

- Charlie