Re: [boost] [lockfree::fifo] Review

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: 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.;