Concurrency

Lock-free can be slower

Progress guarantees do not automatically produce lower latency.

Published · updated · ~1 min read · Difficulty: Advanced

Prerequisites

Lock-free is a property, not a performance result

A lock-free algorithm guarantees system-wide progress. It says nothing about cache-line ping-pong, failed CAS loops, fairness or tail latency under contention.

A well-designed single-writer model can outperform an impressive lock-free structure because it avoids shared writes altogether. The fastest atomic operation remains the one you did not need.

Common failure modes

Choose the execution model first

Define ownership, communication direction and boundedness before selecting atomics. SPSC queues, thread-per-core execution and batching often solve the actual problem with less coherence traffic.

Trade-offs

Single-writer and SPSC designs remove contention by construction, but only where the problem genuinely decomposes into one writer per resource. Force a workload that needs real multi-writer semantics into a single-writer shape and the queue in front of that writer becomes the new bottleneck — the coherence traffic didn't disappear, it moved to a serialization point.

Evidence and related laboratories

The magnitude here is measured on this site, not just asserted: the thread-per-core lab's benchmark shows owned partitions outperforming a shared, lock-guarded pool by roughly 38× in Java and 36× in Rust on the disclosed test hardware, and the CAS contention lab's benchmark shows an uncontended single-writer counter measuring substantially faster than uncontended CAS. Both benchmark pages disclose hardware, method and limitations — see them for the numbers behind this article's claims, and see the SPSC ring buffer and memory ordering labs for the underlying mechanisms.

Sources and further reading