Choose locks from execution context and invariants

Suppose a queue stores both a linked list and a count. The invariant might require the count to equal the number of linked nodes whenever another context observes it. Making only the count increment atomic does not automatically make the combined list-and-count update atomic. Enumerate readers, writers, removal paths, error cleanup, and object destruction before choosing protection. Include interrupt and deferred-work access as well as process-context calls. The relevant failure is not merely two writes at the same instant; a reader may see a partly completed update or retain a reference after the object’s lifetime ends. Correct exclusion and correct lifetime management are related but separate obligations.

Disabling preemption prevents the current task from being involuntarily replaced by another task on that CPU within the applicable region; it does not stop other CPUs from touching shared memory. Disabling local interrupts likewise is not a system-wide lock. Conversely, mutual exclusion without handling local interrupt re-entry can deadlock if an interrupt tries to acquire a lock already held by the task it interrupted. Draw the possible execution edges and ask which mechanism removes each edge. On a non-PREEMPT_RT kernel, an appropriate spin-lock variant can combine cross-CPU exclusion with the needed local protection, but blindly disabling everything broadens latency and hides the intended concurrency contract.

A kernel mutex is a sleeping lock and requires a context where its acquisition may sleep. A hard interrupt handler cannot use it merely because the lock is usually uncontended. In a genuinely atomic section, including one holding a raw spinlock, do not invoke operations that may sleep. Memory allocation flags, user-memory access, and nested helper calls deserve particular scrutiny because a harmless-looking call may have a blocking path. Shorten the region by preparing work before acquiring the lock and deferring blocking work until after release, while preserving ownership and revalidating any assumptions that can change outside protection. Short code is useful, but an audited context contract is the actual correctness criterion.

PREEMPT_RT changes spinlock_t into a sleeping, priority-inheritance-aware implementation based on RT mutex mechanisms. Its acquisition does not disable preemption, and its irq-suffixed operations do not provide the same hardware-interrupt masking semantics as their non-RT counterparts. Raw_spinlock_t remains a strict spinning primitive across configurations and is reserved for cases that truly need those low-level semantics. Do not infer from the RT implementation that arbitrary sleeping calls are now portable while holding a regular spinlock: code must obey the lock’s documented cross-configuration usage rules. Review nesting too; acquiring an RT sleeping lock from a region made atomic by a raw lock or explicit interrupt disabling can be invalid.

Multiple locks introduce an ordering problem beyond the correctness of each individual critical section. If one path holds A while acquiring B and another holds B while acquiring A, both may wait permanently. State a consistent order or redesign ownership so the cycle cannot occur. Lockdep records lock-class relationships and execution-context information to identify dangerous dependency patterns, often before a particular full deadlock interleaving happens. Its reasoning depends on the locking paths exercised and its model; a quiet test run does not establish that every lifetime race or unexecuted path is safe. Assertions about required lock ownership help make the contract visible at helper boundaries.

Once correctness is established, measure contention and hold time separately. A long wait can come from a long owner hold, many short contenders, preemption of an owner where permitted, or unrelated scheduling delay. Lock statistics and targeted traces help separate those causes, but instrumentation itself adds cost. Consider a design with one short shared update and expensive work outside the lock rather than assuming a faster primitive fixes excessive serialization. Per-CPU state can reduce shared contention, yet aggregating it and accessing it safely introduce migration and lifetime questions. Keep the model explicit: a throughput bound from hold durations is not a promise about fairness, priority inheritance, interrupt response, or tail latency on an actual configured kernel.