On 23-Nov-00 Archie Cobbs wrote:
> As a relatively simple exercise in -current kernel programming,
> I'm planning to mutex'ify the ichsmb(4) device driver (this is
> a relatively simple driver that currently uses splhigh()). I'd
> appreciate some feedback if what I'm doing is the right thing.
> The plan is to give each instance of the device a mutex. This
> mutex will be grabbed by both the top level code (when programming
> the chip to do something or reading the results) and the interrupt
> code (when servicing an interrupt).
This should work. Sort of. You probably want to wait a bit until I commit my
cdevsw wrapper patches and an MP safe version of the psm(4) driver which will
help detail what has to happen.
> So far so good.. but what I don't understand is what happens if
> the interrupt thread has to block on the mutex? It seems like all
> other devices sharing the same interrupt (and therefore thread)
> could be indefinitely blocked from servicing their IRQ's. Or is
> it just assumed that the top half will never hold the mutex for
> a "long" time?
It the interrupt thread blocks on the mutex, then yes, that IRQ will be
blocked. However, mutexes are intended to be held for relatively short periods
of time. For example, you can't sleep (SSLEEP) with a mutex, so if you are
blocked, you won't be blocked for very long. Also, since interrupt threads run
at a very high priority, it will run again as soon as the top half releases the
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message