Re: Compiler ordering barriers in C++0x

On 5 май, 03:15, "Chris Thomasson" <cris...@[EMAIL PROTECTED]
> wrote:
> [this is in response to msg #13688, which has not been processed yet...
I
> made a mistake, here is correction...]
>
>
>
> > "Dmitriy V'jukov" <dvyu...@[EMAIL PROTECTED]
> wrote in message
>
>news:c5199756-8669-419e-84e9-1de582eff02e@[EMAIL PROTECTED]
> > [...]
> >> I can prove that I have happens-before relation if I can enforce
> >> correct compiler ordering. Consider following code:
>
> >> std::vector<int> g_nonatomic_user_data;
> >> std::atomic_int g_atomic1;
> >> std::atomic_int g_atomic2;
>
> >> std::vector<int> 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


-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]