التزامن والتشغيل المتوازي في مساحة النواة

Kernel code runs in a brutally concurrent environment: multiple CPUs, preemptible threads, and interrupts that fire anytime. Unprotected shared data leads to race conditions and corruption.

Kernel code runs in two contexts:

• Process context: on behalf of a syscall; can sleep
• Interrupt context: handling hardware; must NOT sleep

The context dictates which locking primitive is legal.

The simplest protection is an atomic operation that completes in a single uninterruptible step. The kernel offers types like atomic_t with helpers that map to lock-prefixed x86 instructions.

On x86 the lock prefix makes a read-modify-write instruction atomic across cores by asserting a cache-line lock.

A spinlock busy-waits until the lock is free. It never sleeps, so it is the only choice in interrupt context. Hold it for the shortest time possible — spinning wastes CPU.

If an interrupt handler tries to take a spinlock already held on the same CPU, you deadlock. Use spin_lock_irqsave to disable local interrupts while holding the lock.

A mutex puts the waiting thread to sleep instead of spinning. It is efficient for longer critical sections but is only usable in process context, never in an interrupt handler.

Quick decision guide:

• Short, may run in IRQ context -> spinlock
• Long, process context, can sleep -> mutex
• Single counter or flag -> atomic

RCU allows lock-free reads of shared data while writers create a new copy and swap a pointer. Readers see either the old or new version, never a torn one. It scales superbly for read-mostly structures.

Compilers and CPUs reorder memory accesses. A memory barrier (smp_mb(), smp_wmb()) forces ordering so other cores observe writes in the intended sequence — vital for lock-free code.

To prevent deadlock: always acquire multiple locks in a fixed global order, keep critical sections tiny, and never call a sleeping function while holding a spinlock or interrupts are disabled.

Test your kernel concurrency knowledge.

You learned kernel synchronization:

• Atomics protect single values via lock-prefixed instructions
• Spinlocks busy-wait and work in IRQ context; use irqsave variants
• Mutexes sleep and are process-context only
• RCU and memory barriers enable scalable lock-free reads