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

Groups > comp.programming.threads > #1806 > 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 Anthony Williams <anthony.ajw@gmail.com> - 2011-01-28 08:12 +0000
    Re: forcing the compiler to reload from memory with c++0x frege <gottlobfrege@gmail.com> - 2011-01-28 19:47 -0800
      Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-29 01:43 -0800

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

frege <gottlobfrege@gmail.com> writes:

> On Jan 27, 6:53 am, Alexander Terekhov <terek...@web.de> wrote:
>> frege wrote:
>>
>> [...]
>>
>> > Anyhow, I would say that this is one of those rare cases where
>> > volatile is the right answer - you just need to adds lots of code
>>
>> Volatile is not the right answer. atomic<> is the rights answer.
>>
>
> Yes, we still need atomic - in the most basic sense - ie an aligned
> int, for example.  But no memory_order_* instructions are needed.

Well, if you use an atomic<int> then you will need to use
memory_order_relaxed explicitly unless you want the default
memory_order_seq_cst.

If you don't use atomic<int> then you have undefined behaviour.

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] | [next] | [standalone]

#1827

On Jan 28, 3:12 am, Anthony Williams <anthony....@gmail.com> wrote:
> frege <gottlobfr...@gmail.com> writes:
> > On Jan 27, 6:53 am, Alexander Terekhov <terek...@web.de> wrote:
> >> frege wrote:
>
> > Yes, we still need atomic - in the most basic sense - ie an aligned
> > int, for example.  But no memory_order_* instructions are needed.
>
> Well, if you use an atomic<int> then you will need to use
> memory_order_relaxed explicitly unless you want the default
> memory_order_seq_cst.

Sorry by "no memory_order_*" I really meant memory_order_relaxed,
which is kind of the anti- memory order in my mind.  But like I
replied elsewhere, I didn't see the (at least technical) difference
between an aligned-int and an atomic with memory_order_relaxed.

>
> If you don't use atomic<int> then you have undefined behaviour.
>
sure

> Anthony

Tony

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

#1834

On 29 янв, 06:47, frege <gottlobfr...@gmail.com> wrote:
> > > Yes, we still need atomic - in the most basic sense - ie an aligned
> > > int, for example.  But no memory_order_* instructions are needed.
>
> > Well, if you use an atomic<int> then you will need to use
> > memory_order_relaxed explicitly unless you want the default
> > memory_order_seq_cst.
>
> Sorry by "no memory_order_*" I really meant memory_order_relaxed,
> which is kind of the anti- memory order in my mind.  But like I
> replied elsewhere, I didn't see the (at least technical) difference
> between an aligned-int and an atomic with memory_order_relaxed.

Volatiles does not need to be atomic. Try to play with volatile
uint64_t on a 32-bit machine.

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