Zachary Turner wrote:
A little late chiming in here, but I think volatile is neither necessary nor sufficient to guarantee that the compiler does not perform such optimizations. If it works, it's due to implementation specific extensions of the volatile keyword, such as those provided by Microsoft's compiler which does indeed guarantee that such optimizations are not performed on volatile variables. However, I don't believe this is the case for all compilers (although it might be true for many). In any case, it's definitely not standards compliant behavior, and my understanding of volatile (which seems to change every time someone publishes a new paper about just how bad it is) is that it's almost completely useless for portable, standards compliant behavior.
Zach _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
By no means is using volatile sufficient for producing correct parallel algorithms. But it is absolutely necessary. The standard places a requirement on conforming implementations that: 1.9.6 The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions 1.9.7 Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place 1.9.11 The least requirements on a conforming implementation are: — At sequence points, volatile objects are stable in the sense that previous evaluations are complete and subsequent evaluations have not yet occurred. That to me sounds like a complete enough requirement that compilers don't perform optimizations that produce "surprising" results in so far as observable behavior in an abstract (single-threaded) machine are concerned. To make that work in a parallel environment we have to augment volatile with either library calls or a correct use of memory barriers. Microsoft's extension is that reads and writes to volatile are always accompanied with a full barrier. Frankly, I don't want that "service"; I'd much rather have a control over that. Andy.;