Re: rw_lock_held

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

> Date: Wed, 7 Feb 2018 14:11:56 +0900
> From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
> 
> On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers <chuq%chuq.com@localhost> wrote:
> > your option (1) sounds fine to me.
> > a better wording for the manpage could be:
> >
> >         Test the lock's condition and return non-zero if the lock is
> >         potentially held by the current LWP and matches the specified
> >         condition.  Otherwise, return zero.
> >
> > thus if we see that lock is held (in write mode) by some other LWP then
> > we know that is not even potentially held by the current LWP.
> 
> I think we don't need "potentially" anymore. And "matches the specified
> condition" is unclear to me (I know it's the original wording). So I prefer
> the following one though it's a bit redundant:
> 
>        rw_write_held() returns non-zero if the lock is held by the current
>        LWP for write.  rw_read_held() returns non-zero if the lock is held
>        by the current LWP for read.  rw_lock_held() returns non-zero if
>        the lock is held by the current LWP for write or read.  Otherwise,
>        these functions return zero.

Fine by me except I would make the last sentence:

   Otherwise, these functions may return zero.
                              ^^^
It is possible for rw_read_held and rw_lock_held to return true even
if the _current_ lwp doesn't hold a read lock as long as _some_ lwp
holds a read lock.  Since these are permissible only for positive
assertions, it is always OK for them to spuriously return true.

We should maybe also introduce rw_write_not_held for handful of cases
in tree that currently say KASSERT(!rw_write_held(...)).