Boost logo

Boost :

Subject: Re: [boost] [lockfree::fifo] Review
From: Andrew Venikov (andrew.venikov_at_[hidden])
Date: 2009-12-08 10:23:02

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:

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:

The observable behavior of the abstract machine is its sequence of reads
and writes to volatile data and
calls to library I/O functions

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

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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at