> Date: Wed, 7 Feb 2018 14:11:56 +0900 > From: Ryota Ozaki <ozak...@netbsd.org> > > On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers <c...@chuq.com> 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(...)).