Comment by aarongolliver
7 years ago
It doesn't say it's a memory barrier, but it absolutely has to be for the code to work.
I agree I should be careful with "first-order approximations", but honestly I was being gentle because I do love drdobbs. But all of the things it talked about have been replaced with things that aren't broken in subtle and hard to debug way.
Volatile simply cannot be used a general purpose, portable, synchronization primitive.
> It doesn't say it's a memory barrier, but it absolutely has to be for the code to work.
No, it doesn't say it because it's not trying to make the point that you assume it's trying to make. Honest question: did you fully read and digest the article before commenting? If so, tell me on precisely which line you saw a lack of a memory barrier causing a problem (describe the race condition & bug you found) and explain how exactly you found that to undermine the point of the article.
You don't even need to read the whole article to see the GP's point: the very first example with flag_ is concurrent, unsynchronized access to a shared volatile, and the article promotes it as "the right way".
Yes, it goes on to elaborate on a basically unrelated use of volatile to control access to member functions on classes, which deserves a separate discussion - but you don't even need to get past the first few paragraphs to see that it promulgates the idea that broken makes concurrent access safe. It doesn't.