[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200331172120.GA2683@voyager>
Date: Tue, 31 Mar 2020 19:21:20 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Simple question regarding read-write locks precedence
On Tue, Mar 31, 2020 at 11:26:46AM -0400, Rich Felker wrote:
> Thanks. While I specifically did not implement (or define a macro for)
> PTHREAD_RWLOCK_PREFER_WRITER_NP because it's misleading to advertise
> support for it when it fundamentally can't work,
> PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP seems like a viable
> extension to support. Anyone else see potential problems supporting it
> that I might be missing?
>
> Rich
I do see one problem: The manpage (the only spec available) contradicts
itself. In the Description section, it says (of the new option):
|Setting the lock kind to this avoids writer starvation as long as any
|read locking is not done in a recursive fashion.
OK, but in the Bugs section:
|Setting the lock kind to PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP
|allows writers to run, but, as the name implies a writer may not lock
|recursively.
Well, which is it? Are writers or readers not supposed to recurse? I
thought writers aren't supposed to recurse, anyway. Or is it possible we
need to file a bug report to Michael Kerrisk? Maybe it was supposed to
say "reader" here, then it would make sense. As it stands, though, the
spec is unclear.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
