During the testing of MDEV-24167, it was noticed that the optimistic rw_lock::read_trylock() approach of using fetch_add(1) and then backing off with fetch_sub(1) will cause starvation of a write lock request. This was more prominent when running under rr replay, but it could occur also otherwise.

It is better to remove rw_lock::read_lock_yield() and use a compare-and-exchange loop for incrementing the lock word during shared lock acquisition. That seems to be the common practice.

No actual hangs have been observed in 10.5, because before MDEV-24167, the rw_lock is never used in connection with any blocking system calls.