summaryrefslogtreecommitdiff
path: root/storage/xtradb/include/usr0sess.ic
diff options
context:
space:
mode:
authorSergey Vojtovich <svoj@mariadb.org>2016-11-24 18:18:00 +0400
committerSergey Vojtovich <svoj@mariadb.org>2016-11-25 12:41:35 +0400
commit1a1749e38c774ce3a3493da2410b19ebe71eccb5 (patch)
tree33322e58da54382e5fc55815231574b4a04d27ae /storage/xtradb/include/usr0sess.ic
parentfb7caad72b5c37e96c69aad63f9589f8b56855d6 (diff)
downloadmariadb-git-1a1749e38c774ce3a3493da2410b19ebe71eccb5.tar.gz
MDEV-11296 - InnoDB stalls under OLTP RW on P8
Threads may fall asleep forever while acquiring InnoDB rw-lock on Power8. This regression was introduced along with InnoDB atomic operations fixes. The problem was that proper memory order wasn't enforced between "writers" store and "lock_word" load: my_atomic_store32((int32*) &lock->waiters, 1); ... local_lock_word = lock->lock_word; Locking protocol is such that store to "writers" must be completed before load of "lock_word". my_atomic_store32() was expected to enforce memory order because it issues strongest MY_MEMORY_ORDER_SEQ_CST memory barrier. According to C11: - any operation with this memory order is both an acquire operation and a release operation - for atomic store order must be one of memory_order_relaxed memory_order_release or memory_order_seq_cst. Otherwise the behavior is undefined. That is it doesn't say explicitly that this expectation is wrong, but there are indications that acquire (which is actually supposed to guarantee memory order in this case) may not be issued along with MY_MEMORY_ORDER_SEQ_CST. A good fix for this is to encode waiters into lock_word, but it is a bit too intrusive. Instead we change atomic store to atomic fetch-and-store, which does memory load and is guaranteed to issue acquire.
Diffstat (limited to 'storage/xtradb/include/usr0sess.ic')
0 files changed, 0 insertions, 0 deletions