> -----Original Message-----
> From: Chuck Swiger [mailto:cswi...@mac.com]
> Sent: Thursday, February 23, 2012 6:21 AM
> To: Desai, Kashyap
> Cc: freebsd-s...@freebsd.org; freebsd-stable; McConnell, Stephen
> Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping
> prohibited
>
> On Feb 22, 2012, at 4:22 PM, Desai, Kashyap wrote:
> > Just curious to know, What is a reason that thread can do blocking
> sleep but can't do unbounded sleep ?
>
> When you block, the scheduler can run other threads and only needs to
> wake up and run your thread after the blocking condition is completed.
>
> However, you don't want to busy-wait in a spin lock/mutex for any
> lengthy period of time. If your thread was allowed to do an unbounded
> sleep, especially in a fast interrupt handler context, what's going to
> wake it up? An NMI like the reset button [1]? :-)
When I started working on freebsd, first thing I noticed was ISR in freebsd are
thread. (special thread). But at least not like linux where we don't have pid
associate with ISR.
So In Freebsd we will have thread id for related isr routine.
Consider that fact, Even in fast interrupts handler context we should be able
to sleep. (e.a pause("mps_pause", (hz/1000));)
Schedule can put thread into wait_queue and eventually when wait condition
meet, thread will be wake by OS.
I mean if we can sleep in fast interrupt handler using mtx_ call, why not
msleep/pause ?
Sorry if I am extending this conversation. I really appreciate kind of help
from freebsd forum.!
` Kashyap
>
> Regards,
> --
> -Chuck
>
> [1]: Well, you could also call STI to permit clock interrupts or
> something else to fire an interrupt, but then your interrupt handler
> needs to be re-entrant. (And watch out for multiple nested interrupts
> blowing out the available stack space....)
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
