The Art Of Atomics: From TSO to Store Buffers

Most atomics explanations either skip the hardware or skip the why. I wanted neither.

So I wrote the post I wished existed. CPU up. No skipped steps.

Here's what it covers:

→ CPUs and threads — what they actually share and why that's already a problem
→ The race — two threads, one variable, both locally correct, globally wrong
→ Three attempts to fix it without atomics — all three fail, for different reasons
→ TSO — the x86 memory model, its one weird exception, and what it actually guarantees
→ The store buffer — why writes hide and what a stale read really means
→ Out-of-order execution — the CPU running your program in secret
→ LOCK — the instruction that makes it stop hiding
→ Real assembly — what your compiler actually emits and why
→ Hardware vs compiler fences — two layers, both necessary
→ Memory orders — relaxed, acquire, release, seq_cst, and what the hardware pays for each
→ Interlocked* and _atomic* — same silicon, different spellings
→ Three patterns in C++ and ASM — spinlock, refcount, once flag, Clang vs GCC
→ False sharing — why correct, carefully ordered code can still silently destroy performance

This is the prequel to a planned series — The Art of High Performance Compute. Atomics are where the machine stops lying to you. Everything else builds on that.

If you're a senior engineer or someone who lives in this space — I'd genuinely appreciate a read. If something's wrong, imprecise, or could be explained better, I want to know. The goal is for this series to be worth reading, not just published.

The Art of Atomics — on the StormWeaver Studios blog.
Blog Page