[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200331152646.GV11469@brightrain.aerifal.cx>
Date: Tue, 31 Mar 2020 11:26:46 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Simple question regarding read-write locks precedence
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
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.
