Thomas De Schampheleire wrote:
Hi,
The timeout(9F) manpage says:
"The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The function called by timeout() is run in interrupt context
and must not sleep or call other functions that might sleep."
Does this mean that a function which is called using a timeout, cannot
use mutex_enter() ?
No. But you should not call cv_wait, or its brethren.
You should not attempt to acquire a lock which will be held by other
functions calling cv_wait, or its brethren. (There are ways to do that
safely, but it requires a fair bit of effort to make sure you do it safely.)
Suppose I have a function A which holds a certain lock, and A calls
function B through timeout. B also requires the lock to be held. What
is the best way to ensure proper operation?
You can use timeout() in this case with the lock. Make sure that A (or
any other functions) don't go to sleep while holding that lock though.
You might also consider using taskq's, which don't have these restrictions.
If I put an ASSERT in B for MUTEX_HELD(...), it will likely fail if A
has finished execution by the time the timeout is called.
If I plainly call mutex_enter from B, would this be a recursive mutex
entry? Is it even allowed from a timeout'ed function?
You should never ASSERT MUTEX_HELD in a code path where the lock is not
owned by the thread doing the ASSERT. So the example you give is erroneous.
You can call mutex_enter from B, and it is not a recursive mutex.
Timeouts always run from a separate thread.
Can timeout be called with a zero-timeout value? In that case I would
like to schedule the other function immediately, but without blocking
the caller.
I think you should investigate using taskq(9F) instead of timeout. It
has the semantics you want.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
