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: Mon, 20 Jun 2011 15:39:05 +0200 Organization: A noiseless patient Spider Lines: 53 Message-ID: <4DFF4D79.767E8F71@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="27554"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tzMZABItHTAXoNdKiMAwGHINSLSivFY0=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:ktKLeuWcEBcGO1P1rVGiWGY6k4Y= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:334 Anthony Williams wrote: [...] > >> "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. > > Anyway, it was you that cited this paper; if you don't think it is > relevant then drop it, and focus purely on the published Intel/AMD specs. It was meant to show that mfence/load/mfence has more fencing than needed. > > > see > > > > http://www.decadent.org.uk/pipermail/cpp-threads/2008-December/001947.html > > That is a SPARC implementation; I see no relevance here other than your The relevance here is that for TSO, implementation with Load: MOV, Store: MOV, MFENCE is SC. > claim that x86-TSO is equivalent to SPARC-TSO (the x86-TSO paper > describes it as "broadly similar"). > > > (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.) > > Yes, that part is "obvious". regards, alexander.