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

["H. Peter Anvin" <hpa@zytor.com>]

<figo1802@gmail.com>
Message-ID: <589ca54b-4171-4164-b9ba-dc3a5bad6376@email.android.com>

Yes, if you have concrete scenarios we can discuss them.

"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>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 "IntelA(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

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

--
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>