Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Alexander Terekhov Newsgroups: comp.programming.threads Subject: Re: questions about memory_order_seq_cst fence Date: Fri, 01 Jul 2011 12:48:13 +0200 Organization: A noiseless patient Spider Lines: 35 Message-ID: <4E0DA5ED.35BA4570@web.de> References: <43eb372b-6517-4914-b647-860f1f7136ba@k15g2000pri.googlegroups.com> <87tybsm5kq.fsf@justsoftwaresolutions.co.uk> <35ec803e-2871-41ce-97ea-8b615b29050f@r33g2000prh.googlegroups.com> <87hb7r5z03.fsf@justsoftwaresolutions.co.uk> <87fwnafd9j.fsf@justsoftwaresolutions.co.uk> <4358686f-7bfb-480e-ae71-a8ce57566ab0@l14g2000pro.googlegroups.com> <871uyuasc0.fsf@justsoftwaresolutions.co.uk> <4DFCAB39.35CDACC8@web.de> <87sjr4r2ej.fsf@justsoftwaresolutions.co.uk> <4f622dc3-ad80-4bde-ba01-28e63ffa27d7@d19g2000prh.googlegroups.com> <38d79317-4242-4f45-8840-ca6bd2cbba85@d22g2000yqn.googlegroups.com> <4E086880.8F382B3D@web.de> <026f1d31-6b71-4aa0-b458-a4b21a10420e@g12g2000yqd.googlegroups.com> Reply-To: terekhov@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="12715"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18eYmyIEYRJol0Xc1k+c0M/QLj0+RCvyoo=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:XvBnDLaCuFJ9uzQ6ixoa4s8HccE= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:374 Anthony Williams wrote: [...] > Right, so it appears that on Itanium we cannot use plain LD and ST for > memory_order_relaxed operations --- at least one of them must be > stronger. For now, I'm not sure whether we can get away with making > only one stronger, or whether we need to go for making both loads and > stores stronger. It turns out that Itanium doesn't respect read-after-read dependence (two loads from the same location without a store to the same location in-between in program order) for plain ld. As long as C++11 requires such coherence (makes sense, PowerPC does respect RAR dependence), ld.acq must be used instead of plain ld. Plain st can not be used for memory_order_relaxed stores as well because in some cases C++11 requires remote write atomicity for memory_order_relaxed stores (Joshua Maurice posted here examples) and hence st.rel (it provides remote write atomicity) must be used instead of plain st. On PowerPC, the situation is better (plain LD and ST can be used for memory_order_relaxed loads/stores) because PowerPC respects RAR and provides cumulativity for lwsync/hwsync fences, see: http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/pldi105-sarkar.pdf Note that under 'modes' model, remote write atomicity is a separate mode and hence plain st can be used for 'very relaxed' (the default) stores even on Itanium (I think that Itanium's incoherence for plain ld sucks; ld.acq must be used for 'very relaxed' (the default) loads under 'modes' model just like under C++11). regards, alexander.