Bill Studenmund <wrstuden@netbsd.org> writes:

> As I understand it, the difficulty comes in when the mutex is held
> by a thread that is not running. In that case, the interrupt handler
> blocks. In that case, the interrupt handler has to be blocked, and
> the interrupt has to be disabled/ignored until serviced. For systems
> with a PIC, we disable the interrupt and cope.

I don't understand Andrew's design well enough to comment directly on
it, but "interrupt handler blocks" in interrupt context is something
that leads to much difficulty in OS design. 

On the other hand, the top/bottom model in which bottom halfs run in
interrupt context with interrupts disabled but aren't allowed to block
and top halfs run in kernel thread context with interrupts enabled
(suitably adjusted for interrupt priority levels on appropriate
architectures) has a long history, scales nicely, and is well
understood. It can also use lock-free communication between the top
and bottom halfs when properly implemented.

It may be more work to get there, but it's an incremental change from
the current NetBSD model, and drivers could be converted as needed,
rather than trying to get everything right in one fell swoop.