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:21 PM, Paul Goyette <paul%whooppee.com@localhost> wrote:
> On Wed, 7 Feb 2018, Ryota Ozaki wrote:
>
>>> 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.
>
>
> I like this version much better.
>
> It is also important to retain the restriction against using these functions
> for making run-time locking decisions...  In particular, it is not
> acceptable to do
>
>         if (!rw_write_held(&my_lock))
>                 rw_enter(&my_lock, RW_WRITER);

rwlock.9 already has the sentence :) :

           These functions must never be used to make locking decisions at run
           time: they are provided only for diagnostic purposes.

  ozaki-r


Home | Main Index | Thread Index | Old Index