cvs commit: src/sys/kern kern_intr.c subr_sleepqueue.c src/sys/geom geom_io.c src/sys/sys proc.h

[Robert Watson]

On Thu, 15 Sep 2005, Scott Long wrote:

>> So is this still possible to use mutexes in I/O paths (g_up/g_down 
>> threads) or it will panic immediatelly?
>> 
>> The policy for now was: using mutexes in a sane way is possible. The 
>> question is: did we went from a warning when WITNESS is enabled to a 
>> panic with INVARIANTS only?
>
> Well, there is a subtle distinction here that isn't well understood. 
> Sleep mutexes "block", they don't "sleep".  "Sleeping" implies that 
> scheduling is lost for the thread for an unbounded period of time. 
> "Blocking" implies that scheduling is lost for a relatively short and 
> bounded period of time. So yes, sleep mutexes are still allowed.

Unless of course you're talking about blocking as in I/O, in which case 
blocking refers to unbounded sleeping associated with waiting on I/O 
events, hence non-blocking I/O.  However, even if you set a file 
descriptor to non-blocking, your thread may still sleep waiting on a mutex 
(bounded sleeps) or on kernel memory (unbounded sleeps).  I try to avoid 
using the term blocking except when talking about file descriptors, and 
then just confuse people by using sleep to mean both "what a mutex can do" 
and "what tsleep does".  The useful distinction basically being a 
convention on the degree to which things are bounded...

Robert N M Watson