Barrier #2 guarentees that the write to _complete gets committed immediately. Otherwise it could remain in a queued state meaning that the read of _complete in B would not see the change caused by A even though B effectively used a volatile read. Of course, this example does not quite do justice to the problem … Read more
Simplest answer is volatile is not needed for multi-threading at all. The long answer is that sequence points like critical sections are platform dependent as is whatever threading solution you’re using so most of your thread safety is also platform dependent. C++0x has a concept of threads and thread safety but the current standard does … Read more
You are going to have a very hard time reproducing this bug. In fact, I would go as far as saying you will never be able to reproduce it using the .NET Framework. The reason is because Microsoft’s implementation uses a strong memory model for writes. That means writes are treated as if they were … Read more
Bottom line (TL;DR): LFENCE alone indeed seems useless for memory ordering, however it does not make SFENCE a substitute for MFENCE. The “arithmetic” logic in the question is not applicable. Here is an excerpt from Intel’s Software Developers Manual, volume 3, section 8.2.2 (the edition 325384-052US of September 2014), the same that I used in … Read more
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
Memory barriers aren’t just to prevent instruction reordering. Even if instructions aren’t reordered it can still cause problems with cache coherence. As for the reordering – it depends on your compiler and settings. ICC is particularly agressive with reordering. MSVC w/ whole program optimization can be, too. If your shared data variable is declared as … Read more