Monty dd5d88bb45 Added query_cache_use_rw_lock to allow concurrent query cache lookups ...

The query cache protected all operations with one exclusive lock
(m_cache_lock_status, guarded by structure_guard_mutex). This
serialized every lookup, even though a lookup mainly reads the
query cache structures.

Added a new global variable, query_cache_use_rw_lock (default OFF).
When set, send_result_to_client() takes a shared (read) lock instead
of an exclusive one, which allows lookups to run concurrently. Having
it as an option makes it possible to benchmark both alternatives with
the same binary and then decide which one to keep.

Implementation:
- try_lock() has a new 'read_lock' argument. The new inline function
  try_read_lock() sets it from query_cache_use_rw_lock.
- Readers are counted in m_readers and leave m_cache_lock_status as
  UNLOCKED. Writers wait until m_readers is 0 and are counted in
  m_waiting_writers. Waiting writers have priority over new readers,
  which ensures that invalidations are not starved by cache hits.
- Readers wait on the new COND_cache_read_lock. wake_up_waiters()
  wakes one waiting writer, or all waiting readers if there is none.
- unlock() is split into unlock() and unlock_internal(). The kind of
  lock to release is deduced from m_cache_lock_status, so none of the
  unlock() callers had to be changed.
- send_result_to_client() updates the query list and the statistics
  under structure_guard_mutex when it only holds a read lock. With a
  write lock this is done as before, without taking the mutex.
- If an engine requests invalidation during a lookup done with a read
  lock, the table key is copied and the invalidation is done after
  the lock is released, as invalidation requires a write lock.
- Added the DEBUG_SYNC point "in_query_cache_hit" used by the new test.

With query_cache_use_rw_lock=0 the code works as before.

Did a simple sysbench run with 64 threads and 200000 simple select queries,
all served from query cache. query_cache_use_rw_lock=1 gave a 2.25x
speedup. The difference to an unmodied MariaDB version for the same
test is 2.3 x faster.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-09 16:48:03 +03:00

23 KiB

Raw Permalink Blame History

View Raw