On Wed, May 14, 2025 at 06:08:43PM +0200, Bruno Haible wrote: > Rich Felker wrote: > > It's using the raw pthread lock and it's completely expected that it > > fails with >10 cores since there will always be multiple readers > > scheduled and no chance for a writer to run. > > Yes, that's the phenomenon known as "writer starvation". > > > This is necessitated by > > POSIX rwlocks being required to be recursive and the impossibility of > > making recursive locking only possible for threads which already hold > > a read lock (due to impossibility to track that in O(1) storage). > > I did a survey of the various behaviours of rwlock implementations [1]. > Find the results there [2]. In particular: > > Solaris 11 > When releasing the last reader lock: > If at least one of the enqueued lock attempts is for writing, one > of them is granted. > When releasing a writer lock: > If at least one of the enqueued lock attempts is for writing, one of > the waiting write attempts is granted (not necessarily the first one). > Otherwise, one of the waiting read attempts is granted. > This implementation does not prefer readers. > This implementation always prefers writers. > > gnulib on native Windows > When releasing the last reader lock: > The first of the enqueued lock attempts is granted. > When releasing a writer lock: > If at least one of the enqueued lock attempts is for writing, the > first one of them is granted. > Otherwise, the first of the waiting read attempts is granted. > This implementation does not prefer readers. > This implementation does not globally prefer writers, only when releasing > a writer lock. > This implementation is deterministic. > > Are you saying that the Solaris 11 and gnulib behaviours are not POSIX > compliant? If so, please can you highlight precisely which sentence in > POSIX [3][4] they are violating? (I don't see the word "recursive" there.)
No, I'm saying that it's impossible to make a conforming implementation that prefers writers *in general*, and that, at least as you've described them, the above two implementstions "prefer readers" most of the time in the heavily contended case with multiple readers (as in the test). They can only "prefer writers" in the relatively rare case where there's a single lock owner at unlock time. Thus they still have the same fundamental starvation issue, just covered up so that you're less likely to hit it rather than having it be obvious right away so that you have to make a proper, reliable fix. If you think I'm mistaken and know of a way to make it so a writer is guaranteed to always get the lock even in the presence of hammering by readers, I'd be interested to hear about it. Rich
