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 <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: questions about memory_order_seq_cst fence
Date: Mon, 27 Jun 2011 13:24:48 +0200
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <4E086880.8F382B3D@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> <cb94d252-d88e-424f-a078-92125c487f53@d1g2000prg.googlegroups.com> <4f622dc3-ad80-4bde-ba01-28e63ffa27d7@d19g2000prh.googlegroups.com> <38d79317-4242-4f45-8840-ca6bd2cbba85@d22g2000yqn.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="32684"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18vthN9nsj2Mi+x8Q0MsNgs3dWqqWKA7Ew="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:C50TpkYeniuFeAFnxlmoKocPFdU=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:365


Anthony Williams wrote:
[...]
> > /***************/
> > // Initially
> > atomic<int> x(0), y(0);
> >
> > // Thread 1:
> > r3 = y.load(memory_order_relaxed);
> > atomic_thread_fence(memory_order_seq_cst);
> > r1 = x.load(memory_order_relaxed);
> >
> > // Thread 2:
> > x.store(1, memory_order_relaxed);
> >
> > // Thread 3:
> > r2 = x.load(memory_order_relaxed);
> > atomic_thread_fence(memory_order_seq_cst);
> > y.store(1, memory_order_relaxed);
> > /***************/
> >
> > In this code, the outcome r1 == 0 && r2 == 1 && r3 == 1
> > is NOT allowed under the C++0x memory model.
> > (29.8p2 and 1.10p16)
> 
> OK
> 
> > But, if we compile the code on IA-64,
> >
> > // Thread 1
> > UL3:   ld   r3 = [y]
> > MF1:   mf
> > UL1:   ld   r1 = [x]
> >
> > // Thread 2
> > US2:   st   [x] = 1
> >
> > // Thread 3
> > UL2:   ld   r2 = [x]
> > MF2:   mf
> > US1:   st   [y] = 1
> >
> > it seems that the outcome r1 == 0 && r2 == 1 && r3 == 1
> > is possible.
> > Isn't it?
> 
> I'm not sure. As far as I can make out from the Itanium memory
> ordering docs, if r2==1 and r3==1 then:
> 
> RV3(US2)->R(UL2)->F(MF2)->RV1(US1)->R(UL3)->F(MF1)->R(UL1)
> 
> That on its own doesn't tell use what r1 is, since RV1(US2) is not in
> that chain.
> 
> Unless there is something that I've missed, there is no constraint
> that requires RV1(US2)->R(UL1), so you are right: r1==0 is permitted.

That's because visibility of 2nd thread's store with respect to 1st
thread can be delayed until after 3rd thread's store is made visible
with respect 1st thread and 1st thread can load 'stale' value of x into
r1 (due to lack of remote write atomicity). Itanium's st.rel aside, on
PowerPC, the most heavy fence (hwsync) would prevent that outcome
(hwsync in 1st thread precludes it from observing 'stale' value of x)
but Itanium's mf is not that strong.

regards,
alexander.