Spinlocks, Preemption, and Interrupt Context

Suppose a device interrupt arrives while the kernel is updating a queue that the interrupt handler also uses. A normal mutex will not work here because the interrupt handler cannot sleep, and it may have interrupted the very code that holds the lock.

The kernel needs a lock that never blocks the current execution context.

A spinlock does this by repeatedly checking the lock until it becomes available.

Because spinning consumes CPU time, spinlocks are suitable only when the critical section is very short and cannot sleep.

Interrupts add one more complication: a spinlock alone cannot stop an interrupt handler on the same CPU from interrupting the lock holder and trying to acquire the same lock. Kernel code therefore combines spinlocks with preemption control or interrupt masking when needed.

This chapter compares spinning with blocking, explains process, interrupt, and soft-interrupt contexts, and shows how spinlocks interact with preemption control, interrupt masking, memory ordering, and no-sleep constraints.