sequential consistency

Sequential consistency is the most intuitive thing you could hope a parallel machine to do — it is what almost everyone unconsciously assumes when they first write multithreaded code. Picture all the cores' memory operations being fed, one at a time, through a single shared turnstile into memory. Each core's own operations go through in the order it issued them, but the turnstile interleaves the different cores however it likes. The result is some single global order that respects each core's program order. If a machine behaves as if there were such a turnstile, it is sequentially consistent.

Stated precisely (Lamport's definition): the result of any execution is the same as if all operations of all cores were executed in some single sequential order, and the operations of each individual core appear in that order in the sequence in the order specified by its program. Two conditions, then: a single total order exists that everyone agrees on, and within that order each core's operations keep their program order. No reordering of one core's own loads and stores relative to each other is allowed to be visible. This is the gold standard against which weaker models are measured — and the mental model that makes reasoning about concurrency tractable.

The honest reality is that almost no high-performance hardware is sequentially consistent, because enforcing it forbids the very optimizations that make cores fast: store buffers, write reordering, and aggressive out-of-order memory must all be reined in or made invisible. So real processors offer weaker, relaxed models and let programmers recover SC-like behavior only where needed, by inserting memory barriers. Sequential consistency is therefore best understood as the ideal you reason with and the contract you build toward with synchronization — not the free default behavior of the machine under your code.