0

I know there are meny questions about volatile but I think I ask a different one. I don't ask what it does (in general), my question is: does the volatile keyword ONLY prevent compiler from optimising code which uses a volatile variable or is there ANYTHING else that this keyword does?

NPS
  • 6,003
  • 11
  • 53
  • 90
  • `volatile` and what it does exactly was covered comprehensively in a question only yesterday http://stackoverflow.com/questions/26307071/does-the-c-volatile-keyword-introduce-a-memory-fence. – sjdowling Oct 12 '14 at 10:41
  • That's exactly why I asked my question and why I asked it this way. It's a simple yes or no question, I don't want a huge list of all the things `volatile` does. – NPS Oct 12 '14 at 10:47

2 Answers2

4

Leave the compiler out. The compiler is the least interesting aspect of C++ and doesn't usually play a role in how you think about the language.

The language has this to say about volatile:

1.9, 1 paraphrased:

Access to volatile objects are evaluated strictly according to the rules of the abstract machine.

...

Accessing an object designated by a volatile glvalue is side effect, which is a changes in the state of the execution environment.

...

The implementation may assume that any thread will eventually do one of the following:

  • ...
  • access or modify a volatile object
  • ...

So, as you can see, volatile objects are in some sense part of the interface of your program with the outside world. One of the consequences is that volatile access is given certain ordering guarantees, but that's just a detail. The bigger picture is that volatile means "may interact with the environment".

Community
  • 1
  • 1
Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • Earlier versions of C++ (without threading) specified even less. Basically, what `volatile` actually means is implementation defined. – James Kanze Oct 12 '14 at 11:07
2

Memory accesses (reads and writes) against volatile variables are guaranteed to occur in the order specified in the program. That's all, really. This means that the compiler is not allowed to reorder them (disabling certain compiler optimizations), but also that additional instructions must be emitted to prevent the CPU from reordering them.

Note that this doesn't prevent all the non-volatile memory accesses from being reordered around the volatile ones. It only ensures that volatile memory accesses will not be reordered with respect to each others (and that they won't be optimized away entirely)

jalf
  • 243,077
  • 51
  • 345
  • 550
  • 1
    I think it's more than just ordering though ? E.g. if you read from a volatile variable twice in succession then the variable must actually be read twice, i.e. it can't just be read once and the value re-used ? – Paul R Oct 12 '14 at 10:35
  • That's part of the deal. You can't preserve the original ordering if you add or remove new calls. As I said, they are "guaranteed to occur in the order specified in the program". In other words, they can't be added, removed or reordered. Sorry if it was unclear. – jalf Oct 12 '14 at 10:38
  • OK - I think that part just needs to be more explicitly stated, although I see now you make a passing reference to this in the last sentence. – Paul R Oct 12 '14 at 10:39
  • 1
    The first paragraph is interesting, I don't have a copy of the standard handy to verify it, but the compilers I know, like g++ do _not_ (or at least did not the last time I looked) emit any additional instructions to prevent the hardware from reoganizing accesses. Arguably, this is contrary to the intent of the standard, but at least in pre-C++11 (from memory), what constitues a volatile access is implementation dependent, and most implementations seem to adopt the rule: a machine instruction which reads or writes has been executed. – James Kanze Oct 12 '14 at 11:11