From: Shri Borde Date: 2009-01-15T07:59:00+09:00 Subject: [ruby-core:21353] Re: Supporting Thread.critical=with native threads Is opening a bug the recommended way to get the spec changed for 1.9*? IMO, nobody *should* depend on descheduling of other threads even on MRI. Given that you do not know where the other threads may be when they were descheduled, I think it is close to impossible to access a piece of data with Thread.critical==true sometimes, and sometimes without setting Thread.critical=true. I have written up the details of the proposed behavior here so that we can think of all the interactions with other APIs etc: http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx Thanks, Shri -----Original Message----- From: Charles.O.Nutter@sun.com [mailto:Charles.O.Nutter@sun.com] On Behalf Of Charles Oliver Nutter Sent: Saturday, January 10, 2009 7:21 AM To: ruby-core@ruby-lang.org Subject: [ruby-core:21245] Re: Supporting Thread.critical=with native threads 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