Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!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: Sat, 18 Jun 2011 14:28:26 +0200 Organization: A noiseless patient Spider Lines: 49 Message-ID: <4DFC99EA.5E824F96@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> Reply-To: terekhov@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="3558"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dj1C1nIsOZPwezItxX5YmmspXS36V1wQ=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:Dpm9yjjN5dL3tfa2mglNWJTNuKk= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:323 Anthony Williams wrote: > > Alexander Terekhov writes: > > >> Incorrect implementation > >> > >> Load Seq_Cst: MFENCE, MOV > >> Store Seq_Cst: MOV, MFENCE > >> > >> is busted because IRIW won't work. > > > > That is my thinking... but according to > > > > 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), see http://www.decadent.org.uk/pipermail/cpp-threads/2008-December/001947.html (obviously, it was meant that two consecutive #StoreLoad/MFENCE barriers, like in "store x, load y" both seq_cst, ought to be reduced to just one by the compiler.) regards, alexander.