Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6.0
Description
In MDEV-20612, MDEV-24142 and related tasks, the InnoDB synchronization primitives were rewritten. On Linux, Microsoft Windows, and OpenBSD, we make use of futex-like system calls. (On Microsoft Windows, srw_mutex and srw_lock are simple wrappers of SRWLOCK; on other platforms they are implemented with futexes.)
According to https://shift.click/blog/futex-like-apis/ there are a few more platforms that we should be able to support:
- FreeBSD: _umtx_op (UMTX_OP_WAIT_UINT_PRIVATE, UMTX_OP_WAKE_PRIVATE)
- DragonflyBSD: umtx_sleep, umtx_wakeup
- Apple macOS: __ulock_wait, __ulock_wake
When futex support is missing, we will fall back to the SUX_LOCK_GENERIC implementation that is based on native mutexes, condition variables and native rw-locks when available. Not only will this increase the memory footprint, but lock_sys_t::hash_latch::release() could be a scalability bottleneck, because it uses a single mutex and condition variable to ‘emulate’ futex so that we can avoid increasing the memory footprint of lock_sys.rec_hash.
To be determined: Are any futex-like operations available on other operating systems where MariaDB Server might be able to run?
- AIX
- HP-UX
- Solaris or its derivatives, such as Illumos or OpenIndiana
Attachments
Issue Links
- relates to
-
MDEV-26781 InnoDB hangs on SPATIAL INDEX when using SUX_LOCK_GENERIC
- Closed
-
MDEV-32788 CMAKE_BUILD_TYPE=Debug build failure with SUX_LOCK_GENERIC
- Closed
-
MDEV-34678 pthread_mutex_init() without pthread_mutex_destroy() if SUX_LOCK_GENERIC
- Closed
-
MDEV-20612 Improve InnoDB lock_sys scalability
- Closed
-
MDEV-25404 read-only performance regression in 10.6
- Closed
-
MDEV-27222 FreeBSD 13.0-p4 build error mariadb-10.6.5
- Closed