Follow @Openwall on Twitter for new release announcements and other news
[<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.