We can only compose the ssux_lock using a writer mutex on systems where the mutex is not re-entrant. There is no such guarantee for the POSIX pthread_mutex_t.

Hence, for systems where only a generic mutex is available, we must retain the old SRW_LOCK_DUMMY implementation that consists of std::atomic<uint32_t>, a pthread_mutex_t and two pthread_cond_t so that in case the ownership of a buf_block_t::lock is transferred to a write completion callback thread, the submitting thread of the write will not wrongly acquire the writer mutex of the buf_block_t::lock while the previously submitted write is in progress. This problem was caught in Microsoft Windows on a system where the tests were run on relatively slow hard disk.

Using a futex-based srw_mutex writer works correctly, because re-entrant acquisition is not allowed and the mutex does not keep track of the holding thread.

I successfully tested the fix on Microsoft Windows both with and without the following patch:

diff --git a/storage/innobase/include/rw_lock.h b/storage/innobase/include/rw_lock.h

index cf02fe26c2c..7bfce1b62f7 100644

--- a/storage/innobase/include/rw_lock.h

+++ b/storage/innobase/include/rw_lock.h

@@ -22,7 +22,7 @@ this program; if not, write to the Free Software Foundation, Inc.,

 #if !(defined __linux__ || defined __OpenBSD__ || defined _WIN32)

 # define SRW_LOCK_DUMMY

-#elif 0 // defined SAFE_MUTEX

+#elif 1 // defined SAFE_MUTEX

 # define SRW_LOCK_DUMMY /* Use dummy implementation for debugging purposes */

 #endif

Performance seems ok, the code has grown to be somewhat complicated. maybe it makes sense to document relationship between different rwlocks in Innodb.

If there was a way to have non-recursive mutexes on all platforms, the fallback implementation for futex-less systems would be simpler. On GNU/Linux (with GNU libc), pthread_mutex_t is non-recursive by default and "just works". On Microsoft Windows, and on some proprietary UNIX systems, mutexes are recursive by default. There is a way to explicitly request a mutex to be recursive, but nothing to request them to be non-recursive. Recursive mutexes are inherently incompatible with "ownership passing", which is a requirement for the asynchronous writes of pages that are protected by buf_block_t::lock.

SRW_LOCK_DUMMY was renamed to SUX_LOCK_GENERIC, because on Microsoft Windows, srw_lock will always wrap SRWLOCK even if that alternative implementation were enabled.

According to https://shift.click/blog/futex-like-apis/ documented futex equivalents do exist on some operating systems beyond Linux, OpenBSD and Microsoft Windows:

• FreeBSD: _umtx_op() (UMTX_OP_WAIT_UINT_PRIVATE, UMTX_OP_WAKE_PRIVATE)
• DragonflyBSD: umtx_sleep(), umtx_wakeup()

Furthermore, C++20 defines std::atomic_wait and std::atomic_notify_one.