Overview of Linux Kernel Synchronization Mechanisms: Atomic Operations, Spinlocks, Semaphores, and Mutexes

Keywords: atomic operation, spinlock, semaphore, mutex, percpu-rwsem

Overview – The article gradually analyzes various synchronization mechanisms in the Linux kernel, from basic atomic operations to advanced mutexes, illustrating their principles, data structures, and key APIs.

1. Atomic Operations

Atomic operations guarantee the integrity of a read‑modify‑write sequence, which is essential for protecting static global variables. A typical increment of a variable a is compiled into three assembly instructions: load, add, and store, which can be pre‑empted between the steps.

Common atomic helper functions (from atomic-fallback.h ) include:

atomic_read(v) – read the value of an atomic variable.

atomic_add_return(i, v) – add i to v and return the new value.

atomic_inc(v) – increment v by one.

atomic_cmpxchg(v, old, new) – compare‑and‑swap; returns the old value.

{}_relaxed , {}_acquire , {}_release – variants with different memory‑barrier semantics.

2. Classic Spinlock

Spinlocks provide mutual exclusion between CPUs for very short critical sections and do not allow sleeping. The Linux kernel uses a queued (FIFO ticket) spinlock, where each requester obtains a ticket number and spins until the service number matches its ticket.

Key data structure (illustrated in the figure) contains a ticket counter, a service counter, and an owner field.

Important API chain:

spin_unlock -> __raw_spin_unlock -> do_raw_spin_unlock -> arch_spin_unlock

The lock acquisition path first tries the fast path __mutex_trylock_fast ; if it fails, it falls back to the slow path which may put the task to sleep.

3. Semaphore

A semaphore is created with a count that represents the number of concurrent holders. When count reaches zero, further requests are placed on a wait list.

Key functions:

semaphore – initialization (sets count to 1 for a binary semaphore).

down – fast path when count > 0 ; otherwise invokes __down which may sleep.

up – increments count and wakes the first waiter if the wait list is not empty.

4. Mutex

Mutexes provide exclusive access with the ability to sleep. The owner field records the holding task, enabling easier debugging of deadlocks.

Data structure highlights:

owner == 0 → lock is free.

Non‑zero owner → lock held; low bits are used for optimistic spin flags.

Key initialization APIs:

DEFINE_MUTEX(name) and mutex_init(&mutex) – both initialize the internal fields.

Lock acquisition flow:

Fast path __mutex_trylock_fast attempts an atomic compare of owner .

If it fails, the slow path __mutex_lock_slowpath may perform optimistic spinning via mutex_optimistic_spin .

When spinning also fails, the task is placed on wait_list and sleeps.

Upon unlock, __mutex_unlock_slowpath wakes the first waiter and may hand off the lock directly (HANDOFF mechanism) to avoid “steal‑lock” scenarios.

Application scenario: suitable for protecting resources where sleeping is acceptable, but not for real‑time contexts such as interrupt handlers.

5. Read‑Write Semaphore (rw_semaphore) and percpu‑rwsem

The article briefly mentions read‑write semaphores and per‑CPU read‑write semaphores, which allow multiple readers or a single writer, further extending the kernel’s synchronization toolbox.

Overall, the document provides a comprehensive, step‑by‑step explanation of kernel synchronization primitives, their internal data structures, and the critical code paths involved in acquisition and release.