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