Path: csiph.com!eeepc.pasdenom.info!news.pasdenom.info!news.dougwise.org!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!weretis.net!feeder3.news.weretis.net!feed.cnntp.org!news.cnntp.org!not-for-mail From: Anthony Williams Newsgroups: comp.programming.threads Subject: Re: forcing the compiler to reload from memory with c++0x 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> <4d4221e9$0$17247$426a74cc@news.free.fr> <947b33d5-2509-4f0c-9256-a7c3de35578e@24g2000yqa.googlegroups.com> <87mxmlxxry.fsf@justsoftwaresolutions.co.uk> <87oc6yxdcw.fsf@justsoftwaresolutions.co.uk> <87sjw8w4b5.fsf@justsoftwaresolutions.co.uk> <87oc6s9o04.fsf@justsoftwaresolutions.co.uk> <87r5bjlchs.fsf@justsoftwaresolutions.co.uk> <87mxm7kkug.fsf@justsoftwaresolutions.co.uk> <4D512A6D.B156FC09@web.de> Date: Tue, 08 Feb 2011 11:49:01 +0000 Message-ID: <87ipwulpaq.fsf@justsoftwaresolutions.co.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:K+mq6HwtCeDiDeFH2S7+cEb/g9I= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 46 Organization: CNNTP NNTP-Posting-Host: 4b3ca87d.read.cnntp.org X-Trace: DXC=Pn8gDTOcX487k2lA7La?I1WoT\PAgXa?1^i_>e\E;`R131?8ZVJ3gM5Gj6PdB418W>gkm;hK`KD@2cEWIod:=?9; X-Complaints-To: abuse@cnntp.org Xref: csiph.com comp.programming.threads:1840 Alexander Terekhov writes: > Anthony Williams wrote: >> >> Andy Venikov writes: >> >> > Man, using stand-alone fences is even more complicated than adding >> > correct ordering semantics to atomic loads and stores. >> >> Yes. I did suggest not having them in C++0x for that reason --- they >> look easy, but actually they're even harder to get right than ordering >> on operations. The others in the room felt that non-memory_order_seq_cst >> atomics were an experts-only feature anyway, so it wasn't an issue. > > I always thought that C++0x acquire load is simply { relaxed load, > acquire fence } and that C++ release store is simply { release fence, > relaxed store }. That's right. However, if you don't follow that pattern rigidly with your fences then it is easy to make mistakes. > Fences are needed to allow code like > > if (atomic_var.load(memory_order_relaxed) == some_interesting_value) { > atomic_thread_fence(memory_order_acquire); > . . . > } > > and > > if (we_have_relevant_changes_to_release) > atomic_thread_fence(memory_order_release); > atomic_var.store(UNLOCKED, memory_order_relaxed); > > resulting in less overhead on platforms which support fences (Sparc, > Alpha, PPC) in the case when fencing is not needed and also allow more > easy porting of existing code with fences to C++0x. Yes. Those were some of the reasons people wanted to keep them. 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