Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.2.3, 10.3.0, 10.4.0, 10.5.0
Description
In MDEV-10813, the function rw_lock_lock_word_decr() was simplified in an incorrect way:
@@ -275,12 +275,11 @@ rw_lock_lock_word_decr(
|
os_rmb;
|
local_lock_word = lock->lock_word;
|
while (local_lock_word > threshold) {
|
- if (os_compare_and_swap_lint(&lock->lock_word,
|
- local_lock_word,
|
- local_lock_word - amount)) {
|
+ if (my_atomic_caslint(&lock->lock_word,
|
+ &local_lock_word,
|
+ local_lock_word - amount)) {
|
return(true);
|
}
|
- local_lock_word = lock->lock_word;
|
}
|
return(false);
|
#else /* INNODB_RW_LOCKS_USE_ATOMICS */ |
Because we sample the local_lock_word only once at the start of the loop, it is possible that the following happens during rw_lock_s_lock():
- Another thread is holding an S-latch, so that local_lock_word will be X_LOCK_DECR-1.
- The other thread will release its S-latch and never come back.
- An infinite loop will occur, because lock->lock_word will be X_LOCK_DECR from that point onwards.
- Only a subsequent S-latch acquisition from another thread could resolve the hang.
Attachments
Issue Links
- is caused by
-
MDEV-10813 Clean-up InnoDB atomics, memory barriers and mutexes
- Closed
- relates to
-
MDEV-22850 Reduce buf_pool.page_hash latch contention
- Closed