Understanding Linux Kernel Mutex: Mechanism, Data Structures, and APIs

In the Linux kernel, a mutex (mutual exclusion) is a sleeping lock that guarantees serialization. Unlike spinlocks, which spin in place when the lock is unavailable, a mutex puts the current thread to sleep, making it unsuitable for interrupt context.

The kernel enforces strict usage rules for mutexes: only the owner may release the lock, a lock cannot be released multiple times, acquiring the same lock repeatedly leads to deadlock, initialization must use the mutex API, a mutex cannot be re‑initialized, and a thread must release all mutexes it holds before exiting.

When DEBUG_MUTEXES is enabled, the kernel checks these rules to prevent misuse.

The traditional mutex consists of a state flag and a wait queue of blocked threads. The current owner holds the mutex; upon release, the first waiter (top waiter) is awakened and competes for the lock.

Linux adds optimistic spinning: if a thread fails to acquire the lock, it may spin on the mutex state for a short period before blocking. This mechanism balances spin‑wait overhead against context‑switch costs and incorporates an MCS lock to reduce cache‑line bouncing.

Data structures:

• struct mutex – the primary mutex object, containing fields such as owner , wait_list , and osq (optimistic spin queue).

• struct mutex_waiter – represents a task waiting on a mutex, linked into the wait list.

• Optimistic spin queue (osq) – a per‑CPU MCS lock chain that groups spinning tasks.

External API (excerpt): functions like mutex_init , mutex_lock , mutex_unlock , mutex_trylock , and related helper functions are provided for kernel modules.

mutex_trylock attempts to acquire the lock without blocking. Its core logic resides in __mutex_trylock_or_owner , which uses atomic operations on the owner field and loops to handle concurrent modifications.

mutex_lock may block. The function might_sleep checks that the call is not made from an atomic context. If the lock cannot be obtained immediately, the thread is placed on the wait list (slow path) and may be woken up later.

The slow path inserts the task at the tail of the wait queue, sets the MUTEX_FLAG_WAITERS flag, and eventually wakes the top waiter. Handoff logic ( __mutex_handoff ) transfers ownership directly to the top waiter to avoid starvation.

Unlocking ( mutex_unlock ) has a fast path when no other thread is waiting: the owner field is cleared. If waiters exist, the slow path clears the owner, handles handoff if needed, and wakes the top waiter.

Conclusion: The article outlines the Linux kernel’s mutex implementation, its performance characteristics on mobile platforms, and notes that OPPO’s kernel team is working on optimizing mutex performance to reduce UI jank caused by blocked threads.