Path: csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Alexander Terekhov <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: forcing the compiler to reload from memory with c++0x
Date: Sat, 29 Jan 2011 14:49:05 +0100
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <4D441AD1.C4D8EC77@web.de>
References: <4d3cee42$0$1209$426a74cc@news.free.fr> <1d21ad0a-db55-460e-aeb6-66f6d19369ea@i13g2000yqe.googlegroups.com> <4d3e2e3f$0$21517$426a34cc@news.free.fr> <4D40A4C7.16E6F9AE@web.de> <69d82db7-34be-4de7-86c4-2f39cc1e6df3@m13g2000yqb.googlegroups.com> <4D415CB9.8E64A6AE@web.de> <0f5da3b3-9991-4f19-bc5e-8462b1a9feef@a28g2000vbo.googlegroups.com> <87ei7xxx9f.fsf@justsoftwaresolutions.co.uk> <8022a201-0d7b-471e-b604-68edb11f43f6@n18g2000vbq.googlegroups.com>
Reply-To: terekhov@web.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: mx01.eternal-september.org; posting-host="3e4Fotn8NP3CUoQPJwS9VQ"; logging-data="7550"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/XQNBsqZdgq7nWAZ+sret+XU/BdqTKAao="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:mr1Kofqk0h8HUVerBJr+m5PA1DA=
Xref: csiph.com comp.programming.threads:1791


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.