On 04/04/2011 01:11 PM, Aldy Hernandez wrote:
1. Synchronized atomic load/stores:
atomic_int atomi;
long double j;
Thread 1:
j = 13.0;
atomi.store(1);
Thread 2:
atomi.load();
As I understand it, the load/stores have acquire/release semantics,
so the store to <j> must happen before the store to <atomi>.
Yep, that does seem to be true for the default memory_order_seq_cst.
Currently, this is not the case on x86-64, because GCC reorders the
stores and the attached atomics-2.C test fails. We emit the
following for thread 1:
flds .LC0(%rip)
movl $1, atomi(%rip)
xorl %eax, %eax
fstpt j(%rip)
mfence
Notice the store of <j> *after* the store to <atomi>. I consider
this a bug and have put this on my laundry list.
Seems plausible, though I don't know the details of the x86_64 memory
model well enough to be sure that it would be possible to observe this
reordering. But then, if your test fails I guess it is. :)
2. Unsynchronized atomic load/stores.
For the "memory_order_relaxed" directive, load/stores are not
synchronized as the previous example, but stores to identical memory
locations must be performed in modification order.
For the following loop, I assume and test that the stores to x[] do
not happen out of order:
for (int i=0; i < SIZE; ++i)
x[i].store(666, memory_order_relaxed);
This is the test in the attached atomics-3.C.
I don't think that's testing what you want to test; those stores are to
the same array, but not to the same memory location.
Jason
