write-preferring-rw-lock does not work with nested read locks.

[byronwatt]

Hi, just a comment about write-preferring-rw-lock.md,

The logic fails if you permit nested read locks.

e.g. if thread A goes:
(1) acquires read lock
(2) acquires read lock (nested)
(3) release read lock
(4) release read lock

If at (1.5) thread B tries to acquire the write lock, then both thread A and thread B hang forever.

Unfortunately I have no suggestion on how to modify the algorithm so that it works with nested read locks.

https://github.com/ORESoftware/live-mutex/blob/dev/docs/write-preferring-rw-lock.md

[ORESoftware]

interesting, thanks for the comment. yeah the RW lock for this library is not ready yet, it's a work in progress.

[ORESoftware]

there must be an explanation somewhere online for the situation you describe, if it's a common flaw in the algorithm?

[byronwatt]

Thanks for responding,... after a bit more googling, I see that the pthread implementation (https://github.com/bminor/glibc/blob/master/nptl/pthread_rwlock_common.c) mentions that recursive rdlock and prefer writers are disallowed.

/* If we prefer writers, recursive rdlock is disallowed, we are in a read
phase, and there are other readers present, we try to wait without
extending the read phase. We will be unblocked by either one of the
other active readers, or if the writer gives up WRLOCKED (e.g., on
timeout).
If there are no other readers, we simply race with any existing primary
writer; it would have been a race anyway, and changing the odds slightly
will likely not make a big difference. */