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

Groups > comp.programming.threads > #1780 > unrolled thread

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

Back to article view | Back to comp.programming.threads

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-01-28 16:44 -0500
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-01-30 22:00 +0000
    Re: forcing the compiler to reload from memory with c++0x Andy Venikov <swojchelowek@gmail.com> - 2011-01-31 14:28 -0500
    Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-29 01:47 -0800

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

On 1/28/2011 3:28 PM, Andy Venikov wrote:
> 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?
> Will using atomic_signal_fence (or atomic_thread_fence for that matter)
> force the compiler to emit a code that will do busy-waiting? Do I
> actually need atomic_thread_fence here or will atomic_signal_fence
> suffice? Both of the fences will have to have an "acquire" semantics,
> right? Normally I would use LoadLoad barriers here, but there no such
> thing in c++0x.
>
> Thanks,
> Andy.

Further on the same topic,

atomic<int> a_int;
...
while (!a_int.get(mode_acquire))
{
}

As understand, in this case the compiler in *NOT* allowed to optimize 
the loop away. Am I wrong?

Thanks,
    Andy.

[toc] | [next] | [standalone]

#1795

Andy Venikov <swojchelowek@gmail.com> writes:

> atomic<int> a_int;
> ...
> while (!a_int.get(mode_acquire))
> {
> }
>
> As understand, in this case the compiler in *NOT* allowed to optimize
> the loop away. Am I wrong?

This doesn't actually impose any additional restrictions over
memory_order_relaxed unless the load actually reads a value written by
another thread with memory_order_release (or equivalent) on the store.

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

[toc] | [prev] | [next] | [standalone]

#1797

On 1/29/2011 4:47 AM, Dmitriy Vyukov wrote:
<snip>

>> Further on the same topic,
>>
>> atomic<int>  a_int;
>> ...
>> while (!a_int.get(mode_acquire))
>> {
>>
>> }
>>
>> As understand, in this case the compiler in *NOT* allowed to optimize
>> the loop away. Am I wrong?
>
>
> In both cases a compiler is allowed to "omit" any *finite* number of
> real "physical" loads. But still it has to do real "physical" loads
> with some finite period, so it can *not* replace the loop with an
> unconditional infinite loop.
>
>

What I meant was can the compiler get rid of the loop alltogether?

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/66520f133423e6dd

[toc] | [prev] | [next] | [standalone]

#1829

On 29 янв, 00:44, Andy Venikov <swojchelo...@gmail.com> wrote:
> On 1/28/2011 3:28 PM, Andy Venikov wrote:
>
>
>
> > 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?
> > Will using atomic_signal_fence (or atomic_thread_fence for that matter)
> > force the compiler to emit a code that will do busy-waiting? Do I
> > actually need atomic_thread_fence here or will atomic_signal_fence
> > suffice? Both of the fences will have to have an "acquire" semantics,
> > right? Normally I would use LoadLoad barriers here, but there no such
> > thing in c++0x.
>
> > Thanks,
> > Andy.
>
> Further on the same topic,
>
> atomic<int> a_int;
> ...
> while (!a_int.get(mode_acquire))
> {
>
> }
>
> As understand, in this case the compiler in *NOT* allowed to optimize
> the loop away. Am I wrong?


In both cases a compiler is allowed to "omit" any *finite* number of
real "physical" loads. But still it has to do real "physical" loads
with some finite period, so it can *not* replace the loop with an
unconditional infinite loop.


--
Dmitry Vyukov

All about lockfree/waitfree algorithms, multicore, scalability,
parallel computing and related topics:
http://www.1024cores.net

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web