Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!weretis.net!feeder1.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!feed.cnntp.org!news.cnntp.org!not-for-mail From: Anthony Williams Newsgroups: comp.programming.threads Subject: Re: questions about memory_order_seq_cst fence References: <43eb372b-6517-4914-b647-860f1f7136ba@k15g2000pri.googlegroups.com> Date: Thu, 16 Jun 2011 08:35:59 +0100 Message-ID: <87boxyfctc.fsf@justsoftwaresolutions.co.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:rkB0SC7s1pc3uiSL7+OWLBR29p8= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 24 Organization: CNNTP NNTP-Posting-Host: 5dd50c2f.read.cnntp.org X-Trace: DXC=Ekn8C;Gfk=m[O`b`RHllLhWoT\PAgXa?aGfg=Y\0KjYf31?8ZVJ3gMeGj6PdB418WnjW@o2`Y5L7mFf;8Mio\>Mc X-Complaints-To: abuse@cnntp.org Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:288 Edek writes: > As a side note, I compiled all ops on x86_64, and atomic::load > is mfence/load/mfence even for relaxed. I'd need some time to analyse > the thing from perspective of other ops implementations in all > orderings, and this leads me to the not so subtle question: Ouch. That is a seriously over-cautious implementation. Atomics should not need any fences on x86_64 unless you actually write atomic_thread_fence(memory_order_seq_cst) See my blog entry for the required operations: http://www.justsoftwaresolutions.co.uk/threading/intel-memory-ordering-and-c++-memory-model.html The only one that is not a plain MOV is a seq_cst store, which is an XCHG. 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