[PATCH] pthread_rwlockattr_setkind_np.3: PTHREAD_RWLOCK_PREFER_WRITER_NP

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

 



On 7/15/20 3:50 PM, Michael Kerrisk (man-pages) wrote:
> On Fri, 26 Jun 2020 at 10:54, Michael Kerrisk (man-pages)
> <mtk.manpages@xxxxxxxxx> wrote:
>>
>> Hi Carlos,
>>
>> Could you comment here, as this was your text in pthread_rwlockattr_setkind_np(3)?
>>
>> On 6/25/20 2:32 PM, Kumar Kartikeya Dwivedi wrote:
>>> Hi,
>>> In pthread_rwlockattr_setkind_np(3), the explanation for
>>> PTHREAD_RWLOCK_PREFER_WRITER_NP reads:
>>>
>>>> This is ignored by glibc because the POSIX requirement to support
>>>> recursive writer locks would cause this option to create trivial
>>>> deadlocks;
>>>
>>> I think this should be "reader locks" instead, since it is
>>> undefined[1] for a thread holding a write lock to call
>>> pthread_rwlock_wrlock(3) again (glibc returns EDEADLK, musl simply
>>> deadlocks). There's no such requirement in POSIX either. Please let me
>>> know if I'm missing something.
>>>
>>> [1]: https://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_wrlock.html

I agree with Kumar, and the comment I provided in commit 0d255e74c0 lines up
with my intent and Kumar's requested correction (which is why it's always important
to comment things to provide intent for the implementation!).

8< --- 8< --- 8<
Clarify that it is recursive read locks on the read-write lock that
make it difficult to implement PTHREAD_RWLOCK_PREFER_WRITER_NP.

Update the libc-alpha URL and provide the URL to the POSIX wording
that is quoted in the comment.

Signed-off-by: Carlos O'Donell <carlos@xxxxxxxxxx>

diff --git a/man3/pthread_rwlockattr_setkind_np.3 b/man3/pthread_rwlockattr_setkind_np.3
index b381972dc..a91c43552 100644
--- a/man3/pthread_rwlockattr_setkind_np.3
+++ b/man3/pthread_rwlockattr_setkind_np.3
@@ -80,7 +80,7 @@ starved.
 This is intended as the write lock analog of
 .BR PTHREAD_RWLOCK_PREFER_READER_NP .
 This is ignored by glibc because the POSIX requirement to support
-recursive writer locks would cause this option to create trivial
+recursive read locks would cause this option to create trivial
 deadlocks; instead use
 .B PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
 which ensures the application developer will not take recursive
@@ -102,7 +102,8 @@ read locks thus avoiding deadlocks.
 .\" the writers to acquire and release the lock, and the writers will be
 .\" suspended waiting for every existing read lock to be released.
 .\" ---
-.\" http://sources.redhat.com/ml/libc-alpha/2000-01/msg00055.html
+.\" https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html
+.\" https://sourceware.org/legacy-ml/libc-alpha/2000-01/msg00055.html
 .\" https://sourceware.org/bugzilla/show_bug.cgi?id=7057
 .TP
 .B PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
-- 
2.26.2




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux