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: Wed, 22 Jun 2011 13:24:09 +0200 Organization: A noiseless patient Spider Lines: 70 Message-ID: <4E01D0D9.5DF5C281@web.de> References: <43eb372b-6517-4914-b647-860f1f7136ba@k15g2000pri.googlegroups.com> <87boxyfctc.fsf@justsoftwaresolutions.co.uk> <4DF9D581.E607BEB4@web.de> <8739jaf59n.fsf@justsoftwaresolutions.co.uk> <4DF9EF9A.911CC74F@web.de> <87wrgm9bxk.fsf@justsoftwaresolutions.co.uk> <4DFA18D0.3A413EED@web.de> <4DFA2086.5791E46@web.de> <87fwn9ahxw.fsf@justsoftwaresolutions.co.uk> <4DFC99EA.5E824F96@web.de> <87hb7ksx0t.fsf@justsoftwaresolutions.co.uk> 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="3717"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+aQs98DGAEnJCyZOd4qvZ0NHw7YTwgzgM=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:/JY/3wV0YPBBTHhWHEOj01NWIsw= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:350 Anthony Williams wrote: [...] > >> > http://portal.acm.org/citation.cfm?id=1926394 > >> > > >> > the "Incorrect implementation" above is actually correct (probably > >> > because according to them, MFENCE has the same semantics as PPC's > >> > hwsync). > >> > >> That paper also says: > >> > >> "Sequentially consistent atomics The proposal above includes > >> two implementations of sequentially consistent atomic reads and > >> writes; one with the x86 locked instructions, and the other with > >> fence instructions on both the reads and writes. However, we can > >> prove that it suffices either to place an mfence before every sc read, > >> or after every sc write, but that it is not necessary to do both. In > >> practice, placing the fence after the sc writes is expected to yield > >> higher performance." > >> > >> i.e. they think that > >> > >> Load SC: MOV > >> Store SC: MOV, MFENCE > >> > >> is a valid implementation. > > > > They are talking about X86-TSO (not actual X86), which is equivalent to > > SPARC-TSO (with #StoreLoad spelled as MFENCE), > > Their X86-TSO paper says that it tries to model actual X86 cpus, and > tries to be consistent with the documented semantics, but favouring > actual CPU behaviour over the specs. I've just checked the recent Intel specs... and according to http://www.intel.com/Assets/PDF/manual/253668.pdf (May 2011) recent X86 hardware (P6 and More Recent Processor Families) *is* a step back to TSO, see "8.2.2 Memory Ordering in P6 and More Recent Processor Families . . . Any two stores are seen in a consistent order by processors other than those performing the stores" and "8.2.3.7 Stores Are Seen in a Consistent Order by Other Processors" (IRIW without any fencing or XCHG) More googling... http://blogs.oracle.com/dave/entry/x86_platform_memory_model_clarifications David Dice reported it back in 2009: "Intel has taken steps toward addressing some of the concerns about potential platform memory model relaxations that I identified in a previous blog entry. Specifically see section 7.2.3.7 of their latest Software Developer's Manual which now guarantees global store ordering." 2009's 7.2.3.7 is current 8.2.3.7 regards, alexander.