[twtw]

The naming is not misleading, because the article says a lot about parallel processing.

It is talking about memory consistency models, for heaven's sake. If you have a uniprocessor, or any kind of concurrency without parallelism, it makes zero sense to talk about memory consistency models because you automatically have sequential consistency and don't have to think about it.

If you don't have a multiprocessor, you don't need to think about memory consistency models. If you have a multiprocessor without parallelism, that's your problem, not the author's.

[gpderetta]

Unfortunately because of compiler optimizations, memory models are important even on uniprocessors.

[twtw]

Sure, and the article discusses that. I was thinking at the instruction level. I tend to think of convincing the hardware to do what you want and convincing the compiler to do what you want separately as an effect of writing code before the languages had specified memory models.

EDIT: Though as I think about it I'm having a hard time thinking of a system in which those compiler optimizations are problematic on a uniprocessor system. It is definitely true that optimizations that are safe on a uniprocessor break on a multiprocessor, but I can't think of any systems that don't (effectively) have a memory barrier when switching between threads. SMT wouldn't see a problem because both threads are on the same processor.

[firethief]

Imagine implementing a simple spinlock, but then substituting relaxed atomics for acquire/release synchronization. The compiler can reorder taking the lock relative to the protected operations and render the lock useless.

[twtw]

Thanks!