From: "k.mckinlay" <k.mckinlay@...>
Date: 2002-02-01T03:14:01+09:00
Subject: Thread schedule/contention

Is there a fixed granularity to threads?  (in the sense that in an 
assembler, interrupts get raised 'between' instructions)

I read (pickaxe book) re Thread.critical:

".... the scheduler will not schedule any existing thread to run. However, 
this does not block new threads from being created and run. Certain thread 
operations (such as stopping or killing a thread, sleeping in the current 
thread, or raising an exception) may cause a thread to be scheduled even 
when in a critical section."

Does this mean that it's possible to have a thread running in a critical 
section, competing with another thread? (in which case what stops them from 
colliding?) or does the wording mean something else?  Also, what (thread) 
creates and runs new threads, if other existing threads don't get scheduled 
to run?  Is there an implication that completion of asynchronous IO could 
cause a new (say, server) thread to start and run, even though another 
thread is in a critical section?  

(When I look at the library for Mutex (thread.rb), I see that locking 
depends on Thread.critical for protection, but that coudn't be guaranteed 
to work if more than one thread might be available  - but of course it does 
work.)

As a further, more specific, example, if I look at Thread.exclusive 
(thread.rb), also used for Mutex, I see:

def Thread.exclusive
  _old = Thread.critical
  begin
    Thread.critical = true
    return yield
  ensure
    Thread.critical = _old
  end
end

Even if _old actually has the same value as Thread.critical when it's 
assigned (which presumes RHS evaluation + assignment is atomic), what stops 
it from being out-of-date (and possibly just plain wrong) by the time of 
(evaluating) the next Ruby expression?

(ruby 1.6.3 in use)