I think it does. See §5.1.2.3/5 and /10, which are normative. The principal purpose of volatile is to deal with arbitrary changes of data values outside the program context of the process in which the code is running (ie asynchronous interrupts). (This does not include threads, which are within the program context and which, because they can run on more than one core, require quite different synchronizations, some of which are not async-signal-safe.)
See also the footnote 134 of §6.7.3/8 (which is non-normative despite the "shall not"): "A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall not be 'optimized out' by an implementation or reordered except as permitted by the rules for evaluating expressions." This is a curious note as, as far as I am aware, it is the one and only reference to memory mapping (and about which I mis-spoke in an earlier posting on this article because it is not in C99 which contains no reference to memory mapping).
Posted Feb 7, 2012 18:38 UTC (Tue) by daglwn (subscriber, #65432)
[Link]
> "It says nothing about interrupts."
Thanks for the correction. But the compiler is still correct here. Volatile doesn't say anything about restricting _when_ it is read or written, only that it will get the "latest" value in a single-thread context.
It's perfectly fine for I/O as long as you can guarantee alignment such that there is no "false sharing."
Betrayed by a bitfield
Posted Feb 7, 2012 19:07 UTC (Tue) by chrisV (subscriber, #43417)
[Link]
I agree. And if you get false sharing between two free-standing variables where the one being operated on is marked volatile, or between fields of a struct where the struct is marked volatile, there is a compiler bug. It is still not clear whether that is the case with the kernel test case (first, the struct was not marked volatile, only one of its fields; and secondly, we don't know whether the test case involved an asynchronous test (as opposed to threads) or not.
Betrayed by a bitfield
Posted Feb 7, 2012 20:01 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
the kernel did not have one field marked volatile, but in the research into the problem, someone (I think it was Linus) tested with volatile and the false sharing was happening there as well.
Betrayed by a bitfield
Posted Feb 7, 2012 23:32 UTC (Tue) by daglwn (subscriber, #65432)
[Link]
> And if you get false sharing between two free-standing variables where the > one being operated on is marked volatile, or between fields of a struct
> where the struct is marked volatile, there is a compiler bug.
No, there isn't.
There isn't. Really.
Volatile does not mean what you think it means.
It's a bit like sequential consistency. Just when you think you understand it, something unexpected happens that is both non-intuitive and perfectly legal.
Betrayed by a bitfield
Posted Feb 8, 2012 15:24 UTC (Wed) by daglwn (subscriber, #65432)
[Link]
Seeing some of your other posts about -pthread, I think we are in agreement. Apologies if I mischaracterized your understanding.
Betrayed by a bitfield
Posted Feb 8, 2012 13:51 UTC (Wed) by nix (subscriber, #2304)
[Link]