CppCon 2026

For decades, lock-free programming has been the go-to optimization for the most contended parts of concurrent programs. The reasoning was simple: locks are slow under contention, so eliminate the locks. This made sense on the hardware of the time, and I should know—I've given several talks explaining how and why to do it. The hardware has changed. Modern CPUs are highly optimized for the operations that make locks fast: cache-line transfers, memory ordering, and speculative execution through lock acquisitions. To set the stage, we will briefly establish why, under high contention, a well-written lock consistently outperforms lock-free atomics and CAS loops. (As an aside, I'll hand you a concrete recipe for a spinlock that actually holds up under extreme contention—and show why systematic backoff, by batching cache-line ownership, is what protects the shared interconnect.) But the core of this talk addresses a completely flipped reality: at low contention, lock-free code decisively outperforms spinlocks, for the most surprising reason. Conventional wisdom assumes an uncontended spinlock is practically free. Using raw hardware performance counters, we will see why it isn't: the implicit synchronization a spinlock imposes—even with no contention at all—is deeply unfavorable to modern out-of-order pipelines, while a single lock-free XADD or CAS, an indivisible read-modify-write, is not. The path everyone assumes is free turns out to be the quietly expensive one. Putting these two facts together—locks winning high contention via cache-line batching, atomics winning low contention by staying out of the pipeline's way—points to a concrete design. I will present a highly optimized MPMC (multi-producer, multi-consumer) queue built on a dual-domain structure that deliberately segregates the contended path from the uncontended one, letting each run on the mechanism the hardware actually favors. We will then walk extensive benchmarks across modern silicon—Intel, ARM server (Graviton/Grace), and Apple (M3)—showing this queue is the fastest, often by wide margins, across most operating regimes. We will also see why the tradeoffs play out so differently per chip, in ways that aren't obvious from the spec sheet, and why "ARM vs x86" is the wrong axis entirely—what matters is the chip's target market, not its instruction set. Finally, no benchmark is complete without honest caveats. I will detail the specific corners where this design can still be beaten, the hidden system costs you pay elsewhere to buy this throughput, and why systems that strictly require progress guarantees—deadlock avoidance, priority inversion, safe execution in a signal handler—mean traditional lock-free programming is not dead. It has simply relocated. If you've ever reached for a complex lock-free algorithm to speed up a highly contended hot path—or wondered what your CPU is actually doing during a mutex unlock—this talk will change your mind about where lock-free programming truly belongs.