Garrett D'Amore wrote:
Erik Nordmark wrote:
[Sorry for the slow response time]
Garrett D'Amore wrote:
I'm not talking about consuming cycles. I'm not talking about wall
clock time considerations. I'm talking about potential deadlocks
due to cv_wait.
You must -not- under any conditions cv_wait while in ip_input's
path. Because you don't know anything about what locks or PIL the
calling context is coming from.
I don't think there is a hard and fast rule on this.
It is true that *typically* a mutex is used with a short or bounded
hold time, and that a condition variable might be used when the hold
time is unbounded.
But there might be subsystems that use a mutex (or rwlock) where the
hold time is unbounded.
And one can use condition variables to create mutual exclusion
primitives that have bounded hold time.
The 'interrupts as threads' support in the Solaris kernel can deal
with all combinations; a mutex_enter on an adaptive mutex will sleep
if the thread holding the mutex is not running.
Thus cv vs. mutex/rwlock is a red herring. What matters is whether
the hold time is bounded or not.
I think you've missed a very important point.
mutexes that are adaptive have priority inheritance, to prevent
priority inversion. condition variables do not.
The problem I see is what happens if the resources you are waiting for
require an interrupt to be processed, but the interrupt thread cannot
run because the processor interrupt is currently held because the
thread you are currently executing on has a higher priority interrupt
level.
In the case of the driver which started this discussion, that argument
does not hold true. The process that will wake the threads sleeping on
the cv is spinning on proc and requires no interrupt. I understand the
basic reason for this "rule" - but in this particular case forcing all
threads entering the driver to spin would be an unnecessary waste of
system resources. It does not buy us any safety against deadlock. In
life there are very few absolutes....
The example you mention above would just be a bug in my opinion.
Its possible that mutexes which do not have high priority interrupt
cookies are free from these problems (because the "interrupts as
threads" design you mentioned), but designing for that seems a bad
idea ... some day the design could change.
So, the hard and fast rule that we have used for years is, don't sleep
while in interrupt context. The STREAMs manual pages say that put()
and srv() fall into the category of things that must follow these
rules (because they may be run while in interrupt context; whether
this ever actually occurs is a matter of debate -- but giving any
different advice would be a major departure from what we've been
telling folks for many years.)
sometimes its ok to be a flip-flopper ;-)
-gary
-- Garrett
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
