Re: [PATCH v6 4/5] MCS Lock: Barrier corrections

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Nov 26, 2013 at 04:46:54PM -0800, H. Peter Anvin wrote:
> On 11/25/2013 07:16 PM, Paul E. McKenney wrote:
> > 
> > My biggest question is the definition of "Memory ordering obeys causality
> > (memory ordering respects transitive visibility)" in Section 3.2.2 of
> > the "Intel(R) 64 and IA-32 Architectures Developer's Manual: Vol. 3A"
> > dated March 2013 from:
> > 
> > http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html
> > 
> > I am guessing that is orders loads as well as stores, so that a load
> > is said to be "visible" to some other CPU once that CPU no longer has
> > the opportunity to affect the return value from the load.  Is that a
> > reasonable interpretation?
> 
> The best pointer I can give is the example in section 8.2.3.6 of the
> current SDM (version 048, dated September 2013).  It is a bit more
> complex than what you have described above.

OK, I did see that example.  It is similar to the one we are chasing
in this thread, but there are some important differences.  But you
did mention that that other example operated as expected on x86, so
we are good for the moment.  I was hoping to gain more general
understanding, but I would guess that there will be other examples
to help towards that goal.  ;-)

> > More generally, is the model put forward by Sewell et al. in "x86-TSO:
> > A Rigorous and Usable Programmer's Model for x86 Multiprocessors"
> > accurate?  This is on pages 4 and 5 here:
> > 
> > 	http://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf
> 
> I think for Intel to give that one a formal stamp of approval would take
> some serious analysis.

I bet!!!

Hey, I had to ask!  ;-)

							Thanx, Paul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>