Re: [PATCH v6 4/5] MCS Lock: Barrier corrections
From: "H. Peter Anvin" <hpa@zytor.com>
Date: 2013-11-25 23:29:52
Also in:
linux-arch
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. -hpa -- 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>