Spinlocks vs Mutexes

Both spinlocks and mutexes provide mutual exclusion, but they handle contention very differently.

How They Work

	Spinlock	Mutex
Waiting thread	Busy-waits (spins in a loop)	Sleeps (yields CPU, context switch)
CPU usage while waiting	100% — wasting CPU cycles	~0% — thread is not scheduled
Latency when lock released	Immediate (already running)	Scheduler must awaken sleeping thread
Best for	Short critical sections, < ~100 cycles	Long critical sections, I/O waits

When to Use Which

Use a spinlock when:

• Critical section is very short (just a few instructions)
• You’re in an interrupt handler or atomic context where sleeping is illegal
• You’re on a multi-core system (spinlock on single core = deadlock)

Use a mutex when:

• Critical section is long (I/O, network, disk)
• Contention is high (many threads competing)
• Power consumption matters (spinning wastes energy)

The Decision Tree

Lock needed?
├─ Critical section << context switch time (< 100 cycles)?
│  └─ YES → Spinlock (spinning is cheaper than sleeping)
├─ Running in atomic/IRQ context?
│  └─ YES → Spinlock (can't sleep in IRQ handler)
├─ Single-core CPU?
│  └─ YES → Disable preemption (spinlock is pointless here)
└─ Otherwise → Mutex (or adaptive mutex)

Linux Adaptive Mutex

Modern Linux uses an adaptive mutex: spin a few times, then sleep if the lock isn’t released quickly. Combines the best of both approaches.

Spinlock Implementation (Conceptual)

void spin_lock(atomic_t *lock) {
    while (atomic_test_and_set(lock, 1) == 1) {
        // CPU relaxation instruction (pause/yield)
    }
}

void spin_unlock(atomic_t *lock) {
    atomic_set(lock, 0);
}