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

Groups > comp.programming.threads > #1791 > 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 Alexander Terekhov <terekhov@web.de> - 2011-01-29 14:49 +0100
    Re: forcing the compiler to reload from memory with c++0x Dmitriy Vyukov <dvyukov@gmail.com> - 2011-01-29 06:52 -0800

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

frege wrote:
> 
> 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.

An aligned-int can be read/written bit/byte/part-wise non-atomically.

atomic<>'s memory_order_relaxed operation is meant to be atomic. BTW,
another shortcoming of C++0x atomic<> is that it doesn't allow to label
noncompeting stores/loads/RMWs which don't need atomicity. I mean
something like memory_order_relaxed_noncompeting label. The OP's ctor
and clear() member function would use it.

regards,
alexander.

[toc] | [next] | [standalone]

#1852

On 29 янв, 16:49, Alexander Terekhov <terek...@web.de> wrote:
> frege wrote:
>
> > 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.
>
> An aligned-int can be read/written bit/byte/part-wise non-atomically.
>
> atomic<>'s memory_order_relaxed operation is meant to be atomic. BTW,
> another shortcoming of C++0x atomic<> is that it doesn't allow to label
> noncompeting stores/loads/RMWs which don't need atomicity. I mean
> something like memory_order_relaxed_noncompeting label. The OP's ctor
> and clear() member function would use it.

I second that it may be useful. I guess they just were not able to
come up with a good 7-letter name for it.

--
Dmitriy V'jukov

[toc] | [prev] | [standalone]

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

csiph-web