Re: atomic memory_order with command or with fence
Maybe I should clarify my question:
Referring to the standard 1.10 and 29.8, in regard to the effects of
atomic_thread_fence (orders
release and acquire) on memory ordering. Although the standard doesn't
give this example explicitly.
On May 24, 9:38 pm, itaj sherman <itajsher...@gmail.com> wrote:
When specifying atomic memory_order_relase/acquire, what is the
difference between specifying on a certain command to a separate
atomic_thread_fence?
Aren't the following options equivalent w.r.t. memory ordering of all
operations:
//option1
x.store( r, memory_order_release );
//option2
atomic_thread_fence( memory_order_release );
x.store( r, memory_order_relaxed );
I'll put this code in functions, to clarify the context of x and r:
template< typename T >
void my_store_release_1( std::atomic<T>& x, T r )
{
x.store( r, memory_order_release );
}
template< typename T >
void my_store_release_2( std::atomic<T>& x, T r )
{
std::atomic_thread_fence( memory_order_release );
x.store( r, memory_order_relaxed );
}
It seems to me that these two functions are equivalent, in having the
same effect on memory orderings.
Is that so?
Is it true that a call to one of these can always be replaced by the
other?
(ofcourse I mean in a conforming implementation, in a program without
data races).
The same I would ask about load and acquire:
and same goes for loads:
//option1
r = x.load( memory_order_acquire );
//option2
r = x.load( memory_order_relaxed );
atomic_thread_fence( memory_order_acquire );
template< typename T >
T my_load_acquire_1( std::atomic<T>& x )
{
T const r = x.load( memory_order_relaxed );
std::atomic_thread_fence( memory_order_acquire );
return r;
}
template< typename T >
T my_load_acquire_2( std::atomic<T>& x )
{
T const r = x.load( memory_order_acquire );
return r;
}
Reading the standard 1.10, 29.8 it seems that these are equivalent,
but it doesn't make it too obvious, as I feel it's supposed to be.
In essence, wouldn't the compiler be allowed to produce the same
output?
I only refer to the fences as in this example, a single non-
conditional fence, not other uses within loops and conditions (where
there's a straight forward performance advantage in avoiding
barriers).
{ quoted signature removed -mod }
Is it also the same for read-modify-write operations? (not the ones
with conditional writes, just the ones that always write). Again it
seems so to me, but the standard doesn't say that explicitly.
itaj
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]