Comment by mehrdadn
7 years ago
That 2-decade-old article took some 5+ pages to thoroughly explain its ideas. Turns out it was (and still is) pretty compelling, and the changes in these past 2 decades don't really affect what it's saying.
You, who've surely carefully read the article, understood it in its entirety, and played around with the notion to get a feel for its upsides and downsides, very insightfully reduced it all down to "very bad advice" with zero elaboration. You find that compelling?
I would be careful with those "first-order approximations".
Volatile is not a memory barrier. Different threads can observe reordered accesses regardless of volatile.
There's a reason that it's been proposed for removal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115...)
Where did you see the article claim it was a memory barrier?
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.
4 replies →
The code in the article requires memory barriers. It doesn't have them. It's broken code.
The author is using volatile as though it implied a barrier.
12 replies →