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
