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

[Scott Long]

Pawel Jakub Dawidek wrote:
> On Thu, Sep 15, 2005 at 07:05:37PM +0000, John Baldwin wrote:
> +> jhb         2005-09-15 19:05:37 UTC
> +> 
> +>   FreeBSD src repository
> +> 
> +>   Modified files:
> +>     sys/kern             kern_intr.c subr_sleepqueue.c 
> +>     sys/geom             geom_io.c 
> +>     sys/sys              proc.h 
> +>   Log:
> +>   - Add a new simple facility for marking the current thread as being in a
> +>     state where sleeping on a sleep queue is not allowed.  The facility
> +>     doesn't support recursion but uses a simple private per-thread flag
> +>     (TDP_NOSLEEPING).  The sleepq_add() function will panic if the flag is
> +>     set and INVARIANTS is enabled.
> +>   - Use this new facility to replace the g_xup and g_xdown mutexes that were
> +>     (ab)used to achieve similar behavior.
> 
> 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.

Scott