| Re: Compiler ordering barriers in C++0x |
|
 |
|
 |
|
 |
|
 |
Group: comp.lang.c++.moderated · Group Profile
Author: Dmitriy VyukovDmitriy Vyukov Date: May 5, 2008 05:49
On 5 п╪п╟п╧, 03:15, "Chris Thomasson" comcast.net> wrote:> [this is in response to msg #13688, which has not been processed yet... I
> made a mistake, here is correction...]
>
>
>
>>> I can prove that I have happens-before relation if I can enforce
>>> correct compiler ordering. Consider following code:
>
>>> std::vector g_nonatomic_user_data;
>>> std::atomic_int g_atomic1;
>>> std::atomic_int g_atomic2;
>
>>> std::vector thread()
>>> {
>>> g_atomic1.store(1, std::memory_order_relaxed);
>>> // compiler store-load fence
>>> if (g_atomic2.load(std::memory_order_relaxed))
>> [...]
>
>> Are you sure that atomic store with 'memory_order_relaxed' semantics
>> injects
>> a #StoreLoad after the operation?
>
> Whoops! I did not read the word COMPILER! Sorry about that. Anyway, I think
> that
> 'g_atomic2.load()' can rise above 'g_atomic1.store()'...
... if you don't use system_wide_synchronize() on "the other side" ;)
It's a sketch of reader-side of asymmetric reader-writer mutex.
Dmitriy V'jukov
| 
