Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #1778

Re: forcing the compiler to reload from memory with c++0x

Show all headers | View raw

Dmitriy Vyukov <dvyukov@gmail.com> writes:

> On Jan 28, 11:01 am, Anthony Williams <anthony....@gmail.com> wrote:
>
>> If you don't think any ordering guarantees are required then use atomic
>> operations with memory_order_relaxed. However, be aware that writes with
>> relaxed operations can be reordered just like non-atomic writes, so you
>> might well need a fence just to prevent the compiler reordering.
>
>
> A bit more formal hair-splitting. Excuse me, but I think that we are
> still in early stage with all that stuff and need to agree on all the
> details.
> Relaxed atomic accesses definitely can be reordered, but still not
> precisely as non-atomic writes. Am I right?

They're not exactly the same as non-atomic writes, no. A relaxed atomic
store is at most one store of exactly the specified value. It may be
omitted if the compiler can see that there is a later store to the same
variable without an intervening operation that would force visibility.

>> If you are only using your fence to prevent compiler reordering then you
>> can use atomic_signal_fence rather than atomic_thread_fence. The former
>> is primarily a compiler directive, and will likely not issue any CPU
>> instructions.
>
> I think that if one does NOT use real signals (or dirty tricks like
> strict affinity of several threads to the same CPU)
> atomic_signal_fence() won't buy you anything. That is, an algorithm
> either works properly with relaxed accesses, or requires
> atomic_*thread*_fence() (or not relaxed atomic accesses). But it can't
> be the case that atomic_*signal*_fence() makes an algorithm work.
> Isn't it?

atomic_signal_fence() is a compiler fence, and prevents reordering by
the compiler. Given:

atomic<int> a(0),b(0);
a.store(1,memory_order_relaxed);
atomic_signal_fence(memory_order_seq_cst);
b.store(2,memory_order_relaxed);

then as I understand it, the compiler must issue the store to a before
the store to b, so that if a signal handler reads b==2 then it will also
read a==1.

This doesn't help with reads by other threads, since relaxed ordering
doesn't ensure visibility, and another thread might still read b==2 but
a==0.

So, it probably doesn't gain you anything in terms of an MT algorithm,
but it does prevent some compiler reordering.

Anthony
-- 
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++0x thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Back to comp.programming.threads | Previous | Next | Find similar

Thread

Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 09:40 +0000

csiph-web