<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mesi on Jasper</title><link>https://jasper-aa64.github.io/tags/mesi/</link><description>Recent content in Mesi on Jasper</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 21 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jasper-aa64.github.io/tags/mesi/index.xml" rel="self" type="application/rss+xml"/><item><title>Trading System Notes #16: Spinlocks</title><link>https://jasper-aa64.github.io/posts/spinlock-implementation/</link><pubDate>Wed, 21 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/spinlock-implementation/</guid><description>Whether a spinlock is fast depends on what its waiters do: if every attempt is a read-modify-write, they drag the lock&amp;rsquo;s line back and forth. Read before you grab, put PAUSE in the loop, back off after losing, and waiting costs the holder almost nothing.</description></item><item><title>Low-Latency Trading — A Cache Case Study: Repricing 64 Options per Tick</title><link>https://jasper-aa64.github.io/posts/low-latency-cache-case-study/</link><pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/low-latency-cache-case-study/</guid><description>One tick touches 140 cache lines, and most of the time goes into waiting for them. None of the four steps changes the computation; they change when data arrives, where it lands and who holds it: put the misses in flight together, ask for the next batch early, hand back lines that are dead after one read, read one line less across the handoff, and leave the lines the other core will read in L3.</description></item><item><title>Low-Latency Trading — MESI Cache Coherence</title><link>https://jasper-aa64.github.io/posts/low-latency-mesi-cache-coherence/</link><pubDate>Sun, 04 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/low-latency-mesi-cache-coherence/</guid><description>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&amp;rsquo;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.</description></item><item><title>Trading System Notes #2: Memory Ordering and Cache Lines</title><link>https://jasper-aa64.github.io/posts/memory-ordering-false-sharing-dependency-chains/</link><pubDate>Tue, 15 Sep 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/memory-ordering-false-sharing-dependency-chains/</guid><description>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.</description></item></channel></rss>