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.