Re: when can we tsleep() ?

[David Young <dyoung%pobox.com@localhost>]

On Sun, Oct 26, 2008 at 09:26:13AM +0000, Andrew Doran wrote:
> On Sat, Oct 18, 2008 at 10:25:17PM +0200, Manuel Bouyer wrote:
> 
> > this is related to kern/39725. We have cpu_intr_p() which tells us
> > if we're in interrupt context or not. But there's other cases where
> > it's not safe to call tsleep (e.g. from soft interrupt context, maybe
> > others). If there a function or check that can tell us if it's safe
> > to use tsleep() or not ?
> 
> There is no function directly available to do that. I don't believe it is
> something you should need to check on the fly other than for an assertion.
> 
> It is safe to sleep with condition variables or tsleep when running within a
> kthread or a user lwp. So if you are running because of kthread_create(), or
> are running because a user process called into the kernel (a system call or
> trap) then you can sleep. Otherwise it is not permitted.
> 
> Soft interrupts also have thread context but can sleep only to acquire a
> mutex or a rwlock. Use of a condition variable or tsleep will cause an
> assertion to fire because those typically indicate a longer wait. It's not
> allowed because the soft interrupts are a limited resource that are shared
> among lots of subsystems. If they stall for any length of time then the
> system will become unresponsive.
> 
> Nothing can sleep in the idle loop, or in a hardware interrupt handler. One
> exception is the interrupt that does kernel preemption. It runs on the the
> preempted LWP's stack, without its own context, and calls to mi_switch().
> However that's done under carefully controlled circumstances, when it is
> known that it's safe to switch.
> 
> Long term sleeps should not happen while holding most locks, for example
> proc::p_lock, as these can cause the system to respond poorly or worst case,
> deadlock. With some locks we can't avoid it and it's not a problem, example:
> vnode locks. There are no runtime assertions to catch these problems so as a
> general rule it's avoided.

This is really helpful.  Such information belongs in, say, a
concurrency(9) or a locking(9).

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24