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.