There are read barriers and write barriers; acquire barriers and release barriers. And more (io vs memory, etc). The barriers are not there to control “latest” value or “freshness” of the values. They are there to control the relative ordering of memory accesses. Write barriers control the order of writes. Because writes to memory are … Read more
The short answer is that the body of the pthread_mutex_lock and pthread_mutex_unlock calls will include the necessary platform-specific memory barriers which will prevent the CPU from moving memory accesses within the critical section outside of it. The instruction flow will move from the calling code into the lock and unlock functions via a call instruction, … Read more
Quoting from the IA32 manuals (Vol 3A, Chapter 8.2: Memory Ordering): In a single-processor system for memory regions defined as write-back cacheable, the memory-ordering model respects the following principles [..] Reads are not reordered with other reads Writes are not reordered with older reads Writes to memory are not reordered with other writes, with the … Read more
Not an answer at the level of the language standard, but some evidence that in practice, the answer can be “two”. And as I guessed in the question, this can happen even if the RMW is seq_cst. I haven’t been able to observe stores being reordered as in the original question, but here is an … Read more
re: your edit: But I do not want to use atomic variable. Why not? If it’s for performance reasons, use them with memory_order_relaxed and atomic_signal_fence(mo_whatever) to block compiler reordering without any runtime overhead other than the compiler barrier potentially blocking some compile-time optimizations, depending on the surrounding code. If it’s for some other reason, then … Read more