Re: [musl] Simple question regarding read-write locks precedence

[Rich Felker <dalias@libc.org>]

On Tue, Mar 31, 2020 at 05:21:06PM +0200, Koen Vandeputte wrote:
> 
> On 31.03.20 17:09, Rich Felker wrote:
> >On Tue, Mar 31, 2020 at 05:05:27PM +0200, Koen Vandeputte wrote:
> >>Hi All,
> >>
> >>I've written a user app which make use of reader-writer locks.
> >>
> >>Topology is pretty simple:
> >>
> >>- 1 writer
> >>
> >>- 4 readers
> >>
> >>
> >>Writes only occur once in a while.
> >>
> >>Readers are heavy users of the lock.
> >>
> >>
> >>The default behavior in musl is Reader precedence.
> >>
> >>In my usecase, it means that a writer never aquires the lock causing
> >>writer starvation.
> >>
> >>Debugging nicely shows that readers also "jump over" the waiting
> >>writer as there is always at least 1 reader present in the critical
> >>section at any time.
> >>
> >>Going through the source code shows that there is no support for
> >>specifying lock attributes which give writers precedence over
> >>readers.
> >>
> >>
> >>Is there an update scheduled to add the required attribute types
> >>which allow writer precedence to avoid starvation?
> >The POSIX model of allowing recursive read locks fundamentally doesn't
> >admit writer preference -- there's no way to distinguish the case of
> >new reader vs an additional recursive lock by an existing reader
> >without O(n) space. If you disallow the latter (recursive locks while
> >a writer is waiting) you get deadlocks all over the place in intended
> >usage model.
> 
> Hi Rich,
> 
> Thanks for the very fast reply.
> 
> I've red about the trivial deadlocks, but isn't this the reason why
> *PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP* exists?
> 
> It's the user's responsibility to avoid recursive reading here ..
> but at least it allows preferred writes.
> 
> 
> See description in: http://man7.org/linux/man-pages/man3/pthread_rwlockattr_setkind_np.3.html

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