Re: rw_lock_held

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Wed, Feb 7, 2018 at 2:01 AM, Chuck Silvers <chuq%chuq.com@localhost> wrote:
> On Tue, Feb 06, 2018 at 07:06:33PM +0900, Ryota Ozaki wrote:
>> Hi,
>>
>> Is there any reason that rw_lock_held checks if it's held
>> by *someone*, not by curlwp? It's confusable and most (or all?)
>> users of the API seem to expect the latter (held by curlwp).
>>
>> Well, rwlock.9 says that rw_*_held behave so, but that's perhaps
>> just out-of-date because rw_read_held and rw_write_held check
>> if it's held by curlwp.
>>
>> So I think we should do either:
>> (1) fix rw_lock_held, or
>>     - probably it would be rw_read_held() || rw_write_held()
>> (2) fix users of rw_lock_held.
>>     - it also would replace rw_lock_held with
>>       rw_read_held() || rw_write_held()
>>
>> I prefer (1) because I think there is no user of the current
>> behavior that is difficult to use for users (it may be useful
>> as an internal utility function though).
>>
>> Any thoughts?
>
>
> 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.

  ozaki-r