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

Groups > comp.programming.threads > #1794

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

Show key headers only | View raw

Andy Venikov <swojchelowek@gmail.com> writes:

> On 1/28/2011 3:01 AM, Anthony Williams wrote:
>>
>> 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.
>
> Sorry to be asking too many "stupid" questions, but this area is
> important to understand.
>
> So, if I have
>
> atomic<int> a_int;
> ...
> while (!a_int.get(relaxed))
> {
> }
>
> The compiler is allowed to optimize the while loop away?

Yes, but with caveats. 

There are no guarantees about how quickly a given thread runs, so it
could be suspended for arbitrary amounts of time at arbitrary points.

If the value of a_int is ever set to non-zero then the compiler is free
to omit the loop, since relaxed operations can read future values, so it
can assume that it read the non-zero future value. It has to be careful
not to invalidate modifcation orders, though --- future reads of a_int
from the same thread must read either the non-zero value that meant the
loop was omitted, or a later value in the modification order of a_int.

This could be achieved by having a_int.get() block until it knew what
that non-zero value was.

If the compiler does not know if a_int is ever set to non-zero, then it
must schedule at least one read of a_int. If it enters the loop, then it
must perform further reads of a_int as required by memory ordering
constraints on other variables. If there are no such constraints, then
it only need issue another read in some finite amount of time (which
could be large).

Such things are entirely QoI: in practice, the compiler will emit a real
read which is run each loop iteration.

> Will using atomic_signal_fence (or atomic_thread_fence for that
> matter) force the compiler to emit a code that will do busy-waiting?

In practice, yes. In principle, if the compiler knows there will be no
signals handled on this thread then atomic_signal_fence imposes no
restrictions.

Compilers try to work with programmers, not against them, so they won't
optimize out such a loop unless they have good reason to believe it
won't execute, such as

a_int.store(1);
while(!a_int.load()){ do_stuff(); } // can be omitted.

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 | Unroll thread

Thread

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

csiph-web