tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rw_lock_held



On Wed, Feb 7, 2018 at 2:29 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> On Wed, Feb 7, 2018 at 2:21 PM, Taylor R Campbell
> <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>>> Date: Wed, 7 Feb 2018 14:14:35 +0900
>>> From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>>>
>>> On Wed, Feb 7, 2018 at 2:55 AM, Taylor R Campbell
>>> <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
>>> >> Date: Tue, 6 Feb 2018 19:06:33 +0900
>>> >> From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>>> >>
>>> >> 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).
>>> >
>>> > I like (1) too, but check for Solaris compatibility?  It is hard to
>>> > imagine that there are correct uses of the current semantics that are
>>> > not also correct uses of (1).
>>>
>>> https://docs.oracle.com/cd/E36784_01/html/E36886/rwlock-9f.html
>>>
>>> They seem to have only rw_read_locked that is compatible to our
>>> rw_read_held.
>>
>> Looks to me like rw_read_locked is actually more like:
>>
>>         KASSERT(rw_read_held(l) || rw_write_held(l));
>>         return rw_read_held(l);
>>
>> or
>>
>>         KASSERT(rw_read_held(l) || rw_write_held(l));
>>         return !rw_write_held(l);
>
> Oops. Yes, I misunderstood rw_read_held.

Well, so the proposed rw_lock_held makes the situation better but
it's not yet what I expected.

Anyway a revised rwlock.9 would be:

           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
           (potentially by the current LWP) for read.  rw_lock_held() returns
           non-zero if the lock is held by the current LWP for write or held
           (potentially by the current LWP) for read.  Otherwise, these
           functions return zero.

It may be better to write just "rw_lock_held is equivalent to
rw_write_held() || rw_read_held()"...

  ozaki-r


Home | Main Index | Thread Index | Old Index