A state is worth adding when the event it optimises is common in the target workload and the resource it saves is the one that limits performance or energy. Each state costs state bits, directory metadata, and above all new transitions and races to verify. Decide from measured or modelled sharing patterns, not from the length of the acronym.
Protocol | Stable states | Bits per line | Optimises | Adds to verify |
|---|---|---|---|---|
MSI | I, S, M | 2 | Nothing beyond correctness | Smallest state space, the baseline |
MESI | adds E | 2 | Read then write of a private line: no upgrade | E to M silent store, H forwarding to a possibly clean holder, PutE |
MOESI | adds E and O | 3 | Dirty line read by others: no memory write or memory read | M to O, O upgrade, Fwd-GetM to O with sharers, PutM from O while sharers remain |
MESIF | adds E and F | 3 | Clean shared read served by one cache, not memory | F hand-off on every read, F eviction, a forward that finds no F copy |
Directory metadata grows too. MESI's exclusive(C0) reuses the exclusive-holder pointer. MOESI's O: C0, sharers {C1} needs a holder pointer and a sharer set at the same time, and MESIF needs an F pointer beside the sharers. For sharer-set cost see Full Bit-Vector Cost.
Almost every design answers the first question yes: E costs no extra bit and the private read-then-write pattern is everywhere. The O and F questions need the profile. The verification column decides close calls: an extra state that saves little in the profile is not worth its races.
Workload | Pattern from profile | What the counts say | Recommendation |
|---|---|---|---|
A: pipeline hand-off. C0 fills a descriptor line each step, C1 and C2 read it | Every line is written by one core then read by two, repeatedly | Simulator, 3 rounds: MOESI 1 memory write and 1 memory read against MESI's 3 and 4, but 40 messages against 34 through H | MOESI when memory bandwidth limits, ideally with direct forwarding so the extra reader legs shorten |
B: mostly private data plus a lookup table written once at start-up | Private lines read then written, shared lines clean and read-mostly | E saves one GetM and Data per private line. O almost never occurs: dirty lines are rarely read by others before eviction | MESI. Consider F only if clean shared misses to far memory dominate the profile |
Workload A's numbers come from Comparing Protocol Traffic. If the same pipeline were limited by interconnect bandwidth instead of memory, the six extra messages would count against MOESI and MESI would be the safer pick. The decision follows the limiting resource.
Yes, in the course model. With one consumer, MOESI sends exactly as many messages as MESI per round and removes the memory write each time, so it adds no messages (only the final eviction carries data, as PutM instead of PutS). The extra messages appear only with a second reader, which MOESI forwards to the O holder instead of serving from memory.