I'm not sure I grasp the high level idea of memory consistency. I understand we are studying how to enforce memory to behave AS IF instructions from many processors are executed in some order, and that this is necessary to implement atomic operations and locks. But once we have atomic operations and locks, is there any reason further reason to care about this program order? My thinking is that whenever the programmer needs to enforce an order, they would use a lock or an atomic operation. When would one need to worry about the effective program order, without actually trying to control it with an atomic operation or lock?

@anon33 I think locking is a way to preserve execution order. Strict consistency means that all operations must have definite order, and that consistency might be "relaxed" where the exact order doesn't matter - e.g. two reads happening together.

@anon33, I think slide 21 provides a good example of why memory consistency is necessary for programs that do not use locks or atomic operations to enforce order.

@anon33 Someone might care about the effective order because different reordering are able to hide memory latency differently. That is the reason why we want to think about consistency: to understand where and when we are ok with reordering to hide latency, and under what conditions we are not. If a programmer then needs a stricter consistency model than what the hardware provides, they will need to use extra synchronization on top of this. However, as a design decision, going with release consistency model under the assumption that programmers can just use locks and atomic operations would mean users would need to think about each load/store in the program, or else suffer from a loss in performance. That's why I think we try to pick a reasonable consistency model for both usability and performance. After that, programmers need to understand the model given to them, as you say, to know when to use synchronization.