a memory consistency model
Coherence answers a question about one address: do all cores eventually agree on the latest value of X? The memory consistency model answers a harder question about several addresses at once: in what order are one core's writes allowed to become visible to another core? Imagine you tidy your desk by first putting a flag up ('I'm done') and then placing the finished report in the tray. A coworker watching might, surprisingly, see the flag go up before the report appears — because the two actions can be reordered on the way out. The consistency model is the contract that says exactly which such reorderings the hardware may expose.
Here is why this is subtle. A modern core, for speed, does not necessarily make its memory operations visible to others in the order the program wrote them — store buffers, caches, and out-of-order execution can let a later write appear before an earlier one to a different core, even while each core's own view stays sequential. The consistency model is the precise specification of which reorderings are permitted, and it is what concurrent code must be written against. The strictest model, sequential consistency, forbids all surprising reorderings; relaxed or weak models (which most real hardware uses) permit many, in exchange for speed, and require the programmer to insert memory barriers to forbid a reordering where it would break correctness.
This matters enormously and is one of the least intuitive corners of computing. Lock-free code, double-checked locking, and many clever synchronization tricks are correct under one consistency model and silently broken under another — the bug appears only rarely, only on some hardware, and is brutal to reproduce. The honest takeaway: parallel hardware does not behave like a simple interleaving of program steps unless you explicitly constrain it. You must know your platform's memory model, or use higher-level primitives (locks, atomics with defined ordering) that encapsulate the barriers for you.
Core A: store data = 42; store ready = 1. Core B: while(ready == 0) wait; read data. Under sequential consistency, when B sees ready == 1 it must also see data == 42. Under a relaxed model, B might see ready == 1 while data is still the old value — unless A inserts a memory barrier between the two stores to force the order.
The consistency model decides whether 'data set before flag set' is guaranteed to be observed in that order — the crux of correct lock-free code.
Coherence and consistency are different: coherence is about one location's copies agreeing; consistency is about the allowed ordering of operations across different locations. A coherent machine can still reorder writes in ways that break naive concurrent code.