cvs commit: src/sys/kern kern_intr.c subr_sleepqueue.c
src/sys/geom geom_io.c src/sys/sys proc.h
rwatson at FreeBSD.org
Thu Sep 15 14:30:07 PDT 2005
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
More information about the cvs-all