https://jasper-aa64.github.io/tags/memory-model/Recent content in Memory-Model on JasperHugoen-usSun, 04 Oct 2026 00:00:00 +0000https://jasper-aa64.github.io/posts/low-latency-mesi-cache-coherence/Sun, 04 Oct 2026 00:00:00 +0000https://jasper-aa64.github.io/posts/low-latency-mesi-cache-coherence/MESI enforces one rule: a cache line has either one core that may write it or any number of cores that may only read it, never both. The four states are the answers to two questions — does anyone else hold this line, and have I changed it? — and every cost in the protocol comes from moving data between layers or waiting for another core to confirm. False sharing, a cached queue cursor and a producer that slows down as readers join are all the same state machine. Coherence still doesn’t make a multi-word read atomic, and it says nothing about the order of writes to different addresses; that is what fences are for.https://jasper-aa64.github.io/posts/memory-ordering-false-sharing-dependency-chains/Tue, 15 Sep 2026 00:00:00 +0000https://jasper-aa64.github.io/posts/memory-ordering-false-sharing-dependency-chains/The store buffer and the cache-coherence protocol are one piece of hardware, but they create two unrelated engineering problems. One is correctness: does a thread see the right value, in the right order — solved by memory_order and release/acquire pairing. The other is performance: how many cycles does touching shared or dependent data cost, even when every value read is already correct — solved by cache-line layout and instruction scheduling. Conflating the two is the single most common confusion in this part of systems programming.