On Mon, Nov 25, 2013 at 03:28:32PM -0800, H. Peter Anvin wrote: > On 11/25/2013 02:58 PM, Tim Chen wrote: > > > > Peter, > > > > Want to check with you on Paul's example, > > where we are indeed writing and reading to the same > > lock location when passing the lock on x86 with smp_store_release and > > smp_load_acquire. So the unlock and lock sequence looks like: > > > > CPU 0 (releasing) CPU 1 (acquiring) > > ----- ----- > > ACCESS_ONCE(X) = 1; while (ACCESS_ONCE(lock) == 1) > > continue; > > ACCESS_ONCE(lock) = 0; > > r1 = ACCESS_ONCE(Y); > > > > Here we can definitely state that the read from Y must have happened > after X was set to 1 (assuming lock starts out as 1). > > > observer CPU 2: > > > > CPU 2 > > ----- > > ACCESS_ONCE(Y) = 1; > > smp_mb(); > > r2 = ACCESS_ONCE(X); > > > > If the write and read to lock act as a full memory barrier, > > it would be impossible to > > end up with (r1 == 0 && r2 == 0), correct? > > > > It would be impossible to end up with r1 == 1 && r2 == 0, I presume > that's what you meant. Yes, that is the correct impossibility. Thank you, Peter! Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>