Re: New diagnostic routine - mutex_ownable()

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 30 Apr 2017 22:12:48 +0000
> From: coypu%sdf.org@localhost
> 
> I have an alternate proposal for the same purpose, but not much of a
> suggestion for yours.
> 
> I find it weird to have two names which kinda mean the same thing but
> also don't, and it's not immediate what the difference is, but not sure
> if I can come up with better names.

These aren't the same thing.  What you said suggests you think the
proposed mutex_ownable is an adaptive version of mutex_owned, but
that's not what it is.  (mutex_owned already works on any mutex, spin
or adaptive.)

mutex_owned(lock) means: Do I own this lock right now?
mutex_ownable(lock) means: Could I acquire this lock if I wanted to
right now?

Thus, mutex_owned(lock) implies !mutex_ownable(lock) -- though since
these are only allowed to be used in assertions, what that really
means is that if KASSERT(mutex_owned(lock)) would pass, then
KDASSERT(mutex_ownable(lock)) would panic.

Here's an example usage pattern:

KDASSERT(mutex_ownable(lock));
if (high probability event) {
        do fast-path stuff;
} else {
        mutex_enter(lock);
        KASSERT(mutex_owned(lock));
        do slow-path stuff;
        mutex_exit(lock);
}

This lets you catch locking bugs early on in code paths that have
high-probability fast paths and low-probability slow paths.  I suggest
KDASSERT rather than KASSERT because mutex_ownable may entail
interprocessor synchronization, which is exactly what the fast path
presumably aims to avoid.

> I feel like we mostly care about adaptive mutexes, how about this
> alternate suggestion?

The mutex(9) API is generally designed so that the distinction is not
significant to most users, so that it doesn't matter whether you're
locking out interrupts or other threads.  I would like to avoid adding
more distinctions -- I'm not really sure the mutex_spin_* operations
are worthwhile themselves.