On Mon Aug 02 2010 at 16:30:03 +1000, matthew green wrote:
this is an incomplete reading of the manual page, and you can not
use mutex_owned() the way you are trying to (regardless of what
pooka posted.) you can't even using it in various forms of assertions
safely. from the man page:
It should not be used to make locking decisions at run time, or to
verify that a lock is not held.
That's the mantra, yes.
ie, you can not even KASSERT(!mutex_owned()).
Strictly speaking you can in a case where you have two locks always
are taken as l1,l2 and released as l2,l1 provided you're not dealing
with a spin mutex. Does it make any sense? no (l2 is useless).
Is it possible? yes.
Now, on to sensible stuff. I'm quite certain that warning was written
to make people avoid writing bad code without understanding locking --
if you need to used mutex_owned() to decide if you should lock a normal
mutex, your code is broken. The other less likely possibility is that
someone plans to change mutex_owned in the future.
Further data point: the same warning is in rw_held, yet it was used to
implement recursive locking in vlockmgr until its very recent demise.
Ignoring man page mantras and focusing on how the code works, I do not
see anything wrong with Paul's use of mutex_owned().
but i'm still not sure why we're going to such lengths to hold a
lock across such a heavy weight operation like loading a module.
that may involve disk speeds, and so you're looking at waiting
millions of cycles for the lock. aka, what eeh posted.
It's held for millions of cycles already now and nobody has pointed out
measurable problems. But if it is deemed necessary, you can certainly
hide a cv underneath. The efficiency requirements for the module lock
are probably anyway in the "who cares wins ... not" spectrum. At least
I'm not aware of any fastpath wanting to use it.
Anyway, no real opinion there. A cv most likely is the safe, no-brainer
choice.