"Dmitriy V'jukov" <dvyukov@[EMAIL PROTECTED]
> writes:
> On 2 май, 14:43, Anthony Williams <anthony_w....@[EMAIL PROTECTED]
> wrote:
> 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))
> {
> g_atomic1.store(0, std::memory_order_relaxed);
> return std::vector<int>();
> }
> // compiler acquire fence
> std::vector<int> local = g_nonatomic_user_data;
> // compiler release fence
> g_atomic1.store(0, std::memory_order_relaxed);
> return local;
> }
>
> It's a kind of Peterson's algorithm *but* w/o store-load memory
> barrier, and w/o acquire and release barriers. The point is that I
> still can prove happens-before relation wrt accesses to
> g_nonatomic_user_data, if I can enforce mentioned compiler barriers.
> Basically I need to ensure that accesses to g_nonatomic_user_data will
> not hoist above or sink below accesses to g_atomic1 in generated
> machine code.
> Now I can do this with _ReadWriteBarrier (msvc) or "__asm__
> __volatile__ ("" : : :"memory")" (gcc).
You're using relaxed atomics. This is dangerous. In particular, relaxed
atomics do NOT provide happens-before relations between threads. In
particular, the relaxed load of g_atomic2 doesn't give you any guarantee
about
the state of g_nonatomic_user_data.
Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
