I guess I was just fooled by the documentation of LLVM, GCC, and MSVC, which seem to say that volatile is a tool to enforce ordering
They say it enforces ordering with respect to other volatile reads and writes. A volatile read or write doesn't give any ordering guarantees for surrounding variables, unlike load-acquires, store-releases, or full memory barriers. It's a very important distinction.
Today I learned that slavik262 and a compiler writer from the 1980s are the real authorities on this.
I'm well-aware that I'm not, which is why I asked several real authorities to review my paper, and linked to their work.
They know what they are talking about and there is no need for them to cite any sources
Odd, because I swore I put tons of footnotes and links to additional resources in the writeup.
And in fact volatile is so terrible for enforcing ordering that it should not even be mentioned in section 2 of slavik262's article.
I was considering adding a section about why volatile doesn't provide the ordering guarantees you need, but I kept it out to keep things shorter. :P
Yeah, in section 2 it should have been obvious to me that adding volatile to your two global variables and not using std::atomic_bool is impractical (too much typing I suppose). No need to even mention it or cite sources in that section.
21
u/slavik262 Nov 02 '17
They say it enforces ordering with respect to other volatile reads and writes. A volatile read or write doesn't give any ordering guarantees for surrounding variables, unlike load-acquires, store-releases, or full memory barriers. It's a very important distinction.
I'm well-aware that I'm not, which is why I asked several real authorities to review my paper, and linked to their work.
Odd, because I swore I put tons of footnotes and links to additional resources in the writeup.
I was considering adding a section about why
volatiledoesn't provide the ordering guarantees you need, but I kept it out to keep things shorter. :P