Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5.4
Description
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.
Attachments
Issue Links
- blocks
-
MDEV-24167 InnoDB unnecessarily uses complex rw-lock implementation
- Closed
- is caused by
-
MDEV-22871 Contention on the buf_pool.page_hash
- Closed