Linux-man Archive on
 help / color / Atom feed
From: Carlos O'Donell <>
To:, Kumar Kartikeya Dwivedi <>
Cc: linux-man <>
Subject: [PATCH] pthread_rwlockattr_setkind_np.3: PTHREAD_RWLOCK_PREFER_WRITER_NP
Date: Thu, 16 Jul 2020 15:50:28 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On 7/15/20 3:50 PM, Michael Kerrisk (man-pages) wrote:
> On Fri, 26 Jun 2020 at 10:54, Michael Kerrisk (man-pages)
> <> 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
>>>> 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]:

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 <>

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
 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
 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.
 .\" ---

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-06-26  8:54 ` POSIX writer locks can't be recursive Michael Kerrisk (man-pages)
2020-07-15 19:50   ` Michael Kerrisk (man-pages)
2020-07-16 19:50     ` Carlos O'Donell [this message]
2020-07-17  8:05       ` [PATCH] pthread_rwlockattr_setkind_np.3: PTHREAD_RWLOCK_PREFER_WRITER_NP Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-man Archive on

Archives are clonable:
	git clone --mirror linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ \
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone