Mutex or Spinlock? The Core Question

Both a mutex and a spinlock exist to give one thread exclusive access to a critical section. The difference is entirely about what happens while a thread is waiting:

• A mutex puts the waiting thread to sleep. The CPU is freed up to run something else, and the scheduler wakes the waiter back up once the lock is released.
• A spinlock makes the waiting thread “spin” in a tight loop, repeatedly checking the lock, burning CPU cycles the whole time, until it becomes free.

That single difference drives almost every rule in this lesson.

Using the Mutex Lock

A mutex in the Linux kernel is declared and used through the API in <linux/mutex.h>. It is the right default choice for process-context code that can afford to sleep while waiting.

#include <linux/mutex.h>
#include <linux/slab.h>

static DEFINE_MUTEX(dev_lock);
static char *shared_buffer;

static ssize_t mydev_write(struct file *filp, const char __user *buf,
                            size_t len, loff_t *off)
{
    char *tmp;

    tmp = kmalloc(len, GFP_KERNEL);   /* may sleep - fine here */
    if (!tmp)
        return -ENOMEM;

    if (copy_from_user(tmp, buf, len)) {
        kfree(tmp);
        return -EFAULT;
    }

    mutex_lock(&dev_lock);
    kfree(shared_buffer);
    shared_buffer = tmp;
    mutex_unlock(&dev_lock);

    return len;
}

Key points about mutexes in current kernels:

• Only usable in process context — never from interrupt handlers.
• The same task that locks a mutex must be the one to unlock it.
• A mutex must never be locked recursively by the same task (use mutex_lock_interruptible() if you need to remain responsive to signals).
• Prefer mutex_lock_interruptible() over plain mutex_lock() in code paths reachable from user space, so a blocked process can still be killed cleanly.

Using the Spinlock

A spinlock, declared via <linux/spinlock.h>, is the right tool when the critical section is short and might be reached from a context that cannot sleep.

#include <linux/spinlock.h>

static DEFINE_SPINLOCK(stats_lock);
static unsigned long packet_count;

static void update_stats(void)
{
    unsigned long flags;

    spin_lock_irqsave(&stats_lock, flags);
    packet_count++;
    spin_unlock_irqrestore(&stats_lock, flags);
}

Notice the use of spin_lock_irqsave() instead of the plain spin_lock(). This matters whenever the same lock could be taken both from process context and from an interrupt handler.

Locking and Interrupts: Why irqsave Exists

If process-context code takes a plain spinlock, and then an interrupt fires on the same CPU whose handler tries to take that same lock, you get a deadlock: the interrupt handler spins forever waiting for a lock held by code that can’t run again until the interrupt handler finishes. spin_lock_irqsave() prevents this by disabling local interrupts before taking the lock and restoring their previous state afterward — flags stores exactly what state to restore, since interrupts might already have been off.

Common Mistakes and Troubleshooting

Best Practices

• Default to a mutex unless you have a specific reason (interrupt context, extremely short critical section) to use a spinlock.
• Keep spinlock-protected code as short and predictable as possible — no loops over user-controlled sizes, no blocking calls.
• Always pair lock acquisition and release through every possible return path.
• Enable CONFIG_PROVE_LOCKING (lockdep) during development — it will flag inconsistent lock ordering and context violations automatically.
• Document what data each lock protects directly above its declaration.

Performance Considerations

Spinlocks are cheap when contention is rare and hold times are tiny — there’s no context-switch overhead. But under heavy contention or long hold times, spinning wastes CPU cycles that a mutex would have handed back to the scheduler. Mutexes cost more per acquisition (potential context switch) but scale far better when a lock might be held for anything longer than a few instructions. Profile before assuming; on modern multicore SoCs, lock contention is a very common hidden bottleneck in embedded Linux drivers.

Security Considerations

Incorrect lock handling — missed unlocks, wrong lock ordering, or locks taken in the wrong context — has historically been the root cause of exploitable use-after-free and double-free bugs in kernel drivers. Treat every new lock you add as something that needs the same review rigor as memory management code, not an afterthought.

Real-World Use Case

A typical network driver uses a spinlock (with _irqsave) to protect a small ring-buffer index that both the hardware interrupt handler and the transmit path touch, while using a mutex to protect larger, sleep-tolerant operations like reconfiguring the device through ethtool ioctls. Mixing the two correctly — spinlock for the fast interrupt path, mutex for the slow configuration path — is standard practice across mainline Linux drivers.

Summary — Key Takeaways

• Mutexes put waiters to sleep; spinlocks make waiters busy-loop.
• Use mutexes in process context, especially around code that can itself sleep.
• Use spinlocks for short critical sections, and reach for spin_lock_irqsave() whenever an interrupt handler might touch the same lock.
• Consistent lock ordering across your whole driver prevents deadlocks.
• Lockdep (CONFIG_PROVE_LOCKING) is your best friend during development.

Conclusion

Choosing between a mutex and a spinlock isn’t a matter of preference — it’s dictated by the execution context your code runs in and how long you need to hold the lock. Get comfortable with the decision table in this lesson, always pair every lock with its unlock on every code path, and lean on lockdep during development. With critical sections, atomicity, mutexes, and spinlocks now under your belt, you have the core synchronization toolkit every Linux kernel and device driver developer relies on daily.

Frequently Asked Questions