This article is nearly 2 decades old and gives very bad advice for multithreaded c++ programming. To a first approximation, volatile should never be used for multithreading safety.
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".
There's a reason that it's been proposed for removal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p115...)
The author is using volatile as though it implied a barrier.
> The author is using volatile as though it implied a barrier.
No, you're just not reading the article. Please go read the article. And I don't mean skim. I mean actually read it with the assumption that you have zero clue what it's going to say, because that's more accurate than your current assumption. Then if you still think you're correct, please explain to exactly which line(s) in the code are broken and how precisely that actually undermines the points the article has been making. You will struggle to do this.
In case it helps, for your reference: the author isn't, and never was, a random C++ dummy.
Simply not true. It has limited use with memory mapped I/O (although even there it misses necessary guarantees), but is not intended to work with threads.
> So all you have to do to make Gadget's Wait/Wakeup combo work is to qualify flag_ appropriately:
class Gadget
{
public:
... as above ...
private:
volatile bool flag_;
};
I spent some time working with Andrei at Facebook, and he's a smart guy, but this article is wrong.
Don't do what he says here.
Volatile needs to go away.
https://news.ycombinator.com/newsguidelines.html
Getting personal, bringing up whether someone read an article properly, making uncharitable interpretations of other comments, snarking, and posting in the flamewar style are all things they ask you not to do and which we're trying to avoid here. Not that your comments were anything like as bad as some that we see, but even in seed form these things have ill effects.
Edit: Someone deleted one of their replies here. Just wanted to say thanks, I read it and I think it'll be helpful moving forward.
I’m pretty sure you did not try to follow the guideline in your initial comments. (see [0])
"This isn't what the article says. For instance, in paragraph n, the author states 'x, y and z.'"
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.
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.
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.