Linux Kernel Synchronization: Atomics, Spinlocks, Semaphores & Mutexes

1. Atomic Operations

Atomic operations are the smallest indivisible actions in the kernel, derived from the physical concept of an atom. They are implemented per‑architecture in include/asm/atomic.h and abstracted in include/asm-generic/atomic.h. The kernel uses them for resource counting, such as reference counters in TCP/IP structures. typedef struct { int counter; } atomic_t; The primary API on ARM platforms includes functions like atomic_add, which rely on the ldrex / strex pair to guarantee atomicity. ldrex marks the memory as exclusive, preventing other cores from accessing it until strex completes the write.

2. Spinlock

A spinlock causes the calling CPU to loop (spin) while waiting for the lock to become free. The lock is non‑preemptible while held.

Implementation relies on a 32‑bit slock field that shares memory with a tickets structure (next and owner fields, each 16 bits). The lock operation increments slock by 2^16, checks owner, and spins until next == owner. Unlock decrements the owner.

Typical API (simplified):

spin_lock(&lock)

spin_unlock(&lock)

spin_lock_irq(&lock)

spin_unlock_irq(&lock)

Performance ranking (fastest to slowest): spin_lock > spin_lock_bh > spin_lock_irq > spin_lock_irqsave. Safety ranking (most to least safe): spin_lock_irqsave > spin_lock_irq > spin_lock_bh > spin_lock.

Usage guidelines:

If the protected resource is accessed only in process and soft‑interrupt contexts, use spin_lock_bh to avoid soft‑interrupt interference.

If the resource is accessed in process, tasklet, or timer contexts, the same spin_lock_bh applies because tasklets and timers are implemented as soft interrupts.

If only tasklet or timer contexts access the resource, plain spin_lock suffices.

If the resource may be accessed from hard‑interrupt context, use spin_lock_irq (or spin_lock_irqsave when interrupts are enabled).

3. Semaphore

Kernel semaphores behave like System V IPC semaphores but are only usable inside the kernel. A semaphore holds a count representing available resources.

Operations:

down – Decrements the count; if the result is negative, the task is placed on a wait queue.

up – Increments the count; if tasks are waiting, one is awakened.

The implementation builds on spinlocks and a wait queue to provide flexible scheduling.

4. Mutex

A mutex allows only one task to hold the lock at a time, enforcing that the same task that acquires the lock must release it. If acquisition fails, the task sleeps on a wait queue.

Structure is similar to a semaphore but replaces the integer count with an atomic_long_t owner field to track the owning task.

Key API:

mutex_lock(&mutex)

mutex_unlock(&mutex)

Modern kernels improve mutexes with optional spin‑on‑owner behavior (configurable via CONFIG_MUTEX_SPIN_ON_OWNER) using an MCS lock algorithm, which reduces latency when the owner is expected to release quickly.

Usage constraints:

Only one kernel path may hold the lock at a time.

The lock owner must be the one to unlock.

Recursive locking is not allowed.

Tasks holding a mutex cannot exit.

Mutexes may sleep, so they must not be used in interrupt or soft‑interrupt contexts.