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

Groups > comp.programming.threads > #1787 > 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 David Jobet <david.jobet@free.fr> - 2011-01-30 17:14 -0500
    Re: forcing the compiler to reload from memory with c++0x Anthony Williams <anthony.ajw@gmail.com> - 2011-02-01 23:33 +0000
    Re: forcing the compiler to reload from memory with c++0x Joshua Maurice <joshuamaurice@gmail.com> - 2011-02-01 15:12 -0800
    Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-31 01:07 -0800

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

;-) I'm slow to get it, isn't it ?

I'm still not sure I understand that.
1.10/25 seems to be talking about a store right ?

So, if I'm doing atomic_int.load(std::memory_order_relaxed)

does 1.10/25 still apply ?

If it applies, then it means that an atomic load relaxed implies :
- no ordering guarantee (that one everybody agrees)
- the load cannot be cached/optimized out, because regardless of the 
ordering model used, we're talking about an atomic here, and operation 
on atomics (even load) must become visible in a finite time (I wasn't 
aware of that one)

Corrolary : if I'm doing my own impl of atomic load relaxed in c++98, 
does it mean that even a load relaxed implies a memory clobber so that 
the compiler cannot optimize the value out ?

Tx

David

Dmitriy Vyukov wrote:

> On Jan 28, 4:54 am, David Jobet <david.jo...@free.fr> wrote:
>> > No memory barriers necessary (at least for T == int).
>>
>> This is exactly what the paper says, and that's why I did not see
>> anything in the beginning about a need for memory ordering.
>>
>> If the compiler cannot reorder for T=int, then the load_acquire and
>> store_release are not absolutely required right ?
>>
>> Then I still don't see how to force a reload based on the atomic 
lib...
>> Is it a shortcoming or are we precisely supposed to use volatile in 
that
>> case ?
> 
> N3225 1.10/25
> An implementation should ensure that the last value (in modification
> order) assigned by an atomic or
> synchronization operation will become visible to all other threads 
in
> a finite period of time.
> 
> --
> Dmitriy V'jukov

[toc] | [next] | [standalone]

#1805

Joshua Maurice <joshuamaurice@gmail.com> writes:

> On Jan 30, 2:14 pm, David Jobet <david.jo...@free.fr> wrote:
>> If it applies, then it means that an atomic load relaxed implies :
>> - no ordering guarantee (that one everybody agrees)
>
> Actually, I don't think that I agree.
>
> I admit I'm not the best on this, but it's my understanding that each
> atomic variable has a modification order, and no reads can read values
> in an order which is inconsistent with this modification order. Is
> this right? Ex:
>
>   //all loads and stores are std::memory_order_relaxed
>   //start up the two threads simultaneously
>
>   //initial condition
>   x = 0;
>
>   //thread 1
>   x = 1;
>   x = 2;
>   x = 3;
>   x = 4;
>
>   //thread 2
>   cout << x << endl;
>   cout << x << endl;
>   cout << x << endl;
>   cout << x << endl;
>
> It's my understanding that the program may not print the following. Is
> that correct?
>   1
>   3
>   2
>   4

Yes, that is correct.

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]

#1816

On Jan 30, 2:14 pm, David Jobet <david.jo...@free.fr> wrote:
> ;-) I'm slow to get it, isn't it ?
>
> I'm still not sure I understand that.
> 1.10/25 seems to be talking about a store right ?
>
> So, if I'm doing atomic_int.load(std::memory_order_relaxed)
>
> does 1.10/25 still apply ?
>
> If it applies, then it means that an atomic load relaxed implies :
> - no ordering guarantee (that one everybody agrees)

Actually, I don't think that I agree.

I admit I'm not the best on this, but it's my understanding that each
atomic variable has a modification order, and no reads can read values
in an order which is inconsistent with this modification order. Is
this right? Ex:

  //all loads and stores are std::memory_order_relaxed
  //start up the two threads simultaneously

  //initial condition
  x = 0;

  //thread 1
  x = 1;
  x = 2;
  x = 3;
  x = 4;

  //thread 2
  cout << x << endl;
  cout << x << endl;
  cout << x << endl;
  cout << x << endl;

It's my understanding that the program may not print the following. Is
that correct?
  1
  3
  2
  4

I agree that a memory_order_relaxed operation imposes no ordering
requirements on any /other/ objects, but there is some ordering
requirements with reads and writes on that atomic object.

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

#1819

On 31 янв, 01:14, David Jobet <david.jo...@free.fr> wrote:
> ;-) I'm slow to get it, isn't it ?

As of now, you don't yet hit my record of slowness of understanding of
the topic :)

> I'm still not sure I understand that.
> 1.10/25 seems to be talking about a store right ?

No. For a store to become visible, it must be (informally) actually
written to memory *and* actually *read* from memory. So it's about
both.


> So, if I'm doing atomic_int.load(std::memory_order_relaxed)
>
> does 1.10/25 still apply ?
>
> If it applies, then it means that an atomic load relaxed implies :
> - no ordering guarantee (that one everybody agrees)
> - the load cannot be cached/optimized out, because regardless of the
> ordering model used, we're talking about an atomic here, and operation
> on atomics (even load) must become visible in a finite time (I wasn't
> aware of that one)

Yes, that's right.

> Corrolary : if I'm doing my own impl of atomic load relaxed in c++98,
> does it mean that even a load relaxed implies a memory clobber so that
> the compiler cannot optimize the value out ?

Ummm... I'm not sure... I think that you will be of a safer side if
you put a memory clobber. Because loads must not be completely
optimized away, and even relaxed loads of the same variable must not
be reordered. It boils down to what exactly guarantees your compiler
provides without a memory clobber.

--
Dmitriy V'jukov

[toc] | [prev] | [standalone]

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

csiph-web