Re: should sync builtins be full optimization barriers?

[Andrew MacLeod <amacleod at redhat dot com>]

> Hi,
>
> On Tue, 13 Sep 2011, Andrew MacLeod wrote:
>
> > Your example was not about regular stores, it used atomic variables.
> This reads as if there exists non-atomic variables in the new C++
> mem-model.  Assuming that this is so, why do those ugly requirements of
> not introducing new data races also apply to those non-atomic datas?
Why is it ugly to avoid introducing a data race into a race-free 
program?  I would think that is a basic necessity for a multi threaded 
program.

There are normal everyday shared variables like we've always had, and 
there are the new atomic variables which have slightly different 
characteristics.

The C++11 memory model asserts that a program containing data races 
involving *non-atomic* variables has undefined semantics. The compiler 
is not allowed to introduce any data races into an otherwise correct 
program.

Atomic variables are effectively serialized across the system.  When 2 
threads write to an atomic, one will fully happen before the other and 
*all* threads see it happen in that order. The order may not be 
predictable from one run of the program to another, but all the threads 
in a system will see a consistant view of an atomic.  This may 
make them more expensive to use since writes can't be delayed, cache 
lines may have to be flushed, or other memory subsystems may need to get 
involved to execute the operation properly.

All atomic operations also have a memory model parameter which 
specifies one of 6 synchronization modes. When the atomic value is being 
read or written,  it controls how other outstanding shared memory 
operations may also be flushed into the system at the same time, 
assuring them visibility in other threads.  Since atomic operations may 
have these side effects, there are serious restrictions on how they can 
be moved and modified by the compiler, as well as what optimizations can 
be performed around them.  For now, the optimizers are simply treating 
them as function calls with side effects and doing very little.

Andrew