Re: atomic memory_order with command or with fence
On Tuesday, 29 May 2012 20:39:27 UTC-4, itaj sherman wrote:
//thread#1
int data;
std::cin >> data;
atomic_data.store( data, memory_order_relaxed );
atomic_flag.store( 1, memory_order_relaxed ); // <-- store operation X
std::atomic_thread_fence( memory_order_release ); // <-- fence A
//thread#2
std::atomic_thread_fence( memory_order_acquire ); // <-- fence B
int const current_flag = atomic_flag.load( memory_order_relaxed ); //
<-- load operation Y
int const current_data = atomic_data.load( memory_order_relaxed );
if( flag == 1 ) {
//it might be possible to load the value of store operation X even
when fence A did not occur yet.
Ah, I see, this is the source of the confusion. Atomic operations,
and the use of memory models on atomic operations or
fences (e.g. sequentially correct, acquire-release, relaxed) are
pretty much independent from thread synchronization. They provide
no synchronization guarantee between threads, they provide
happens-before relationship between atomic operations.
Let me give you a short example
(credit goes to C++ Concurrency in Action):
std::atomic< bool > x,y,z;
void write_x_then_y()
{
x.store( true, std::memory_order_relaxed );
y.store( true, std::memory_order_release );
}
void read_y_then_x()
{
// y is used as synchronization point
// by spin waiting for y to be set to true
while( !y.load( std::memory_order_acquire ) );
if( x.load( std::memory_order_relaxed ) )
z.store( true, std::memory_order_relaxed );
}
int main()
{
x = false;
y = false;
z = false;
std::thread a( write_x_then_y );
std::thread b( read_y_then_x );
// synchronization point with thread a...
a.join();
// ... and b
b.join();
// z cannot be 0
assert( z.load() );
}
As you can see, there is an explicit synchronization point,
between thread 'a' and 'b' (see the spin-wait on y).
The acquire-release semantic is used to make sure that once
y is set to be true, the store to x also becomes visible in
thread b.
So the acquire-release semantic introduced a happens-before
relationship between y and x store operation, and it has
absolutely nothing to do with intra-thread synchronization,
only the ordering of atomic operations relative to each other.
Fences are similar, just they are not tied to any atomic operation.
If you remove the spin waiting on y:
void bad_read_y_then_x()
{
y.load( std::memory_order_acquire );
if( x.load( std::memory_order_relaxed ) ) ++z;
}
then of course anything could happen, y might be true or false,
but if it is true, then x is guaranteed to be true; otherwise x
might be true or false, depending on the exacty scheduling of the
threads, so this version of the function introduces a race
condition.
Again, enforcing certain memory model on atomic operations or
fences does not introduce synchronization point between
threads; on the other hand they can be used to create a
synchronization point (e.g. spin-wait).
-- Zoltan
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]