Prerequisites

The Core Difference: Sleep or Spin

Every discussion of mutex vs spinlock in the Linux kernel comes down to one question: what should a thread do while it waits for a lock it cannot get right now?

A mutex lets the CPU do something useful with the waiting thread’s time slice, which is great — but the wake-up path costs real microseconds of scheduling latency. A spinlock burns CPU cycles while waiting, which is wasteful if the wait is long, but it avoids the scheduling overhead entirely, which matters when the critical section is extremely short.

Rule 1: A Mutex Can Sleep — So It Cannot Be Used Everywhere

Because a blocked mutex puts the calling thread to sleep, a mutex can only ever be used in process context, where sleeping is legal. You must never try to acquire a mutex from an interrupt handler, a softirq, a tasklet, or any other atomic context — doing so is a kernel bug, and on a debug-enabled kernel it will trigger a “scheduling while atomic” warning.

#include <linux/mutex.h>

static DEFINE_MUTEX(driver_data_lock);

static void update_shared_counter(int *counter, int delta)
{
    mutex_lock(&driver_data_lock);
    *counter += delta;
    mutex_unlock(&driver_data_lock);
}

This pattern is perfect for code that runs from a system call, an ioctl handler, or any other process-context path where a brief sleep while waiting is completely acceptable.

Rule 2: A Spinlock Never Sleeps — So It Is Safe in Atomic Context

A spinlock never puts the caller to sleep, which is exactly why it is safe to use inside interrupt handlers and other atomic contexts where sleeping is forbidden. The trade-off is that the code holding a spinlock must be short, since every other CPU trying to take that same lock is actively burning cycles until it is released.

#include <linux/spinlock.h>

static DEFINE_SPINLOCK(ring_buffer_lock);

static void push_to_ring_buffer(int value)
{
    unsigned long flags;

    spin_lock_irqsave(&ring_buffer_lock, flags);
    /* short critical section only */
    ring_buffer_write(value);
    spin_unlock_irqrestore(&ring_buffer_lock, flags);
}

Notice the irqsave/irqrestore variant here. This is the correct choice whenever the same lock could also be taken from an interrupt handler, since it disables local interrupts for the duration of the critical section — directly preventing the interrupt-context deadlock pattern discussed in our locking guidelines lecture.

Spinlock Variants at a Glance

Decision Checklist: Mutex or Spinlock?

How PREEMPT_RT (Kernel 6.12+) Changes This Picture

Kernel 6.12 mainlined the PREEMPT_RT patchset, and this genuinely affects the mutex vs spinlock decision. On a PREEMPT_RT-enabled kernel, an ordinary spinlock_t is internally converted into a sleeping, priority-inheritance-aware lock, very similar in behavior to a mutex, so that a low-priority holder cannot block a high-priority real-time task indefinitely. Only raw_spinlock_t retains the traditional non-preemptible, busy-wait behavior on an RT kernel, and it is reserved for the small amount of code that genuinely must never be preempted, such as certain low-level scheduler or interrupt-controller internals.

For most driver authors targeting general-purpose Linux, ordinary spinlock_t and mutex usage as shown above is still correct. The raw_spinlock_t distinction only becomes relevant when you are writing code intended to run correctly on real-time targets, such as industrial control or robotics platforms built on PREEMPT_RT.

Real-World Use Cases

Common Mistakes and Troubleshooting

Best Practices

Performance and Security Considerations

Performance: Spinlocks are cheaper for very short, frequently-taken critical sections on multi-core systems because they avoid context-switch overhead; mutexes are cheaper overall when contention is common and waits can be longer, since they free the CPU instead of burning cycles.

Security: A driver that mistakenly uses a spinlock around a long or unbounded operation can be pushed into a denial-of-service state by an attacker who can trigger that path repeatedly from multiple CPUs — another reason critical section length deserves careful review in any driver exposed to external input.

Summary / Key Takeaways

Conclusion

The mutex vs spinlock decision is really a question about context and duration: can this code sleep, and how long will it hold the lock? Get those two answers right and the choice practically makes itself. Combine that with the lock-ordering discipline from the previous lecture, and you already have the foundation most kernel synchronization bugs never get past. Keep following this free Linux kernel development course for more hands-on lectures on kernel internals and device driver development.

Frequently Asked Questions