被坑了一把，mysql 5.7版本引入LF_HASH来用于MDL子系统，在频繁进行申请和释放metadata lock时数据库可能会crash,
BUG#26502135: MYSQLD SEGFAULTS IN MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL
Server sometimes exited when multiple threads tried toacquire and release metadata locks
simultaneously (forexample, necessary to access a table). The same problem could have
occurred when new objects were registered/deregistered in Performance Schema.
The problem was caused by a bug in LF_HASH - our lock free hash implementation which
is used by metadata lockingsubsystem in 5.7 branch. In 5.5 and 5.6 we only use LF_HASH
in Performance Schema Instrumentation implementation. So for these versions, the problem was limited to P_S.
The problem was in my_lfind() function, which searches for the specific hash element by going
through the elements list. During this search it loads information about element checked such
as key pointer and hash value into local variables. Then it confirms that they are not corrupted
by concurrent delete operation (which will set pointer to 0) by checking if element is still in the list.
The latter check did not take into account that compiler (andprocessor) can reorder reads in such
a way that load of key pointer will happen after it, making result of the checkinvalid.
This patch fixes the problem by ensuring that no such reordering can take place.
This is achieved by usingmy_atomic_loadptr() which contains compiler and processor
memory barriers for the check mentioned above and othersimilar places.
The default (for non-Windows systems) implementation of my_atomic*() relies on old __sync
intrisics and implementsmy_atomic_loadptr() as read-modify operation. To avoid scalability/performance penalty associated with addition ofmy_atomic_loadptr()'s we change the my_atomic*() to
use newer __atomic intrisics when available. This new default implementation doesn't have such a drawback.
如有侵权，请联系 firstname.lastname@example.org 删除。