[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200331150912.GU11469@brightrain.aerifal.cx>
Date: Tue, 31 Mar 2020 11:09:12 -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: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.
Do you have any suggested approaches for making this better?
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.
