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 <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: questions about memory_order_seq_cst fence
Date: Thu, 30 Jun 2011 14:26:19 +0200
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <4E0C6B6B.81E28269@web.de>
References: <43eb372b-6517-4914-b647-860f1f7136ba@k15g2000pri.googlegroups.com> <it5sht$i7j$1@node2.news.atman.pl> <b7657dae-d49f-4859-8020-b5d76bfae2cd@p9g2000prh.googlegroups.com> <itbb7k$uhh$1@node2.news.atman.pl> <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> <87oc1xajr3.fsf@justsoftwaresolutions.co.uk> <4DFA2342.52931D8@web.de> <87k4clai0h.fsf@justsoftwaresolutions.co.uk> <hNpKp.4587$Z71.4302@newsfe21.iad> <87boxxahfj.fsf@justsoftwaresolutions.co.uk> <98uKp.16038$SG4.15177@newsfe03.iad> <2671e224-80a9-4e11-a224-64240676069f@y27g2000prb.googlegroups.com> <871uyt3pns.fsf@justsoftwaresolutions.co.uk> <4DFB6257.8C513BD7@web.de> <87wrgk34ip.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="3739"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+SmE8RH0i4oGoRYjxeS+QA1varvOX8htw="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:3VKRN4yIhtVZMU5kE0FbUlRjKis=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:372


Anthony Williams wrote:
> 
> Alexander Terekhov <terekhov@web.de> writes:
> 
> > Anthony Williams wrote:
> > [...]
> >> SC fences should order relaxed reads, but the final result was that they
> >> don't, as it was too expensive on some architectures (such as IA-64).
> >
> > Care to elaborate? What is the problem regarding IA-64?
> 
> I don't remember, and my notes don't say. I think there was some
> discussion that relaxed loads would have to be more than just a plain LD
> instruction if SC fences were to order them, but I really don't remember
> the details, and wasn't privy to the entire discussion anyway.

(from the ongoing email discussion regarding 
http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html )

<Forward Quoted>

Hans Boehm wrote:
[...]
> > [load relaxed]
> >
> >> The problem with a plain ld is that it can be reordered with other
> >> loads from the same location, violating cache coherence.
> >
> > Do you mean that
> >
> > (initially: x = 0)
> >
> > T1: st x = 1;
> > T2: r1 = ld x; r2 = ld x;
> >
> > r1 == 1, r2 == 0 is allowed due to unordered loads?
> >
> > Well, that's really interesting...
> 
> According to the spec, yes.  Whether any implementations allow that, 
> I do not know.
[...]
> Memory_order_relaxed indeed appears to be entirely useless on Itanium.
[...]
> Abbreviating the example, everything is relaxed, except fences are 
> seq_cst:
> 
> Thread 1:               Thread 2:          Thread 3:
> r3 = y (1)		  x = 1              r2 = x (1)
> fence1                                     fence2
> r1 = x (0)                                 y = 1
> 
> We conclude by 29.8p2 that fence2 happens-before fence1.
> 
> Since the initializing write of zero to x precedes the explicit 
> store to x in modification order, and the thread 3 read of x 
> sees the later one, so must the thread 1 read of x, so this is 
> indeed disallowed.
> 
> For the Itanium spec, I'm referring to 
> http://download.intel.com/design/itanium/downloads/25142901.pdf , 
> "A Formal Specification of Intel Itanium Processor Family 
> Memory Ordering", Oct. 2002.
> 
> In the Itanium translation with st, this indeed does not appear 
> to be enforced.  The store to x can occur and become locally 
> visible before anything else (except the initializing write), 
> and remotely visible on thread 3 shortly thereafter, without 
> imposing any constraints on remote visibility at thread 1.  And, 
> in spite of my earlier claim, I think the same issue arises if 
> we use acquire/release operations on y instead of the fences.  
> Thus my natural inclination to blame all of our problems on 
> fences isn't even correct here :-)
> 
> I really need write atomicity in order to get the kinds of 
> transitivity guarantees I need, and only st.rel provides those.
> 
> This seems to have no impact on RMW operations, since those 
> become globally visible in a single order, even if they are only 
> acquire operations.

regards,
alexander.