Locking a MTX_DEF inside an interrupt thread

[John Baldwin]

On Friday, December 12, 2014 2:34:10 am Martin Galvan wrote:
> 2014-12-11 16:58 GMT-03:00 Navdeep Parhar <nparhar at gmail.com>:
> > MTX_DEF mutexes can block but never sleep, and it is perfectly safe to 
acquire
> > them in an ithread.
> 
> Thanks a lot for your answer. At first I was a bit confused on what
> the actual difference between "blocking" and "sleeping" was, but then
> I read the "Bounded vs Unbounded Sleep" section from locking(9) and it
> cleared things out a bit.
> 
> I still don't understand why can't we sleep (i.e. do an 'unbounded
> sleep') inside an ithread. What would be the problem, exactly?

Interrupts (and ithreads) need to "work" during low-memory conditions when 
malloc() could block.  Consider the case of shared interrupts where your 
driver shares an ithread with the storage driver that needs to use its 
interrupt to complete a DMA write of a dirty page to free up memory.  If you 
sleep in the shared ithread then the storage interrupt handler will never run 
and the system would deadlock.  This also means that even in non-ithread 
context unbounded sleeps cannot be done while holding a mutex.  This ensures 
that as long as CPU is available, you can always make forward progress.

You can always defer slower, more expensive tasks to a different context via a 
taskqueue that your interrupt handler schedules.

-- 
John Baldwin