[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
> 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(...)).
Main Index |
Thread Index |