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.
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.)
-- Garrett
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
