On Wed, Nov 29, 2017 at 08:46:02PM +0100, Peter Zijlstra wrote: > On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote: > > > While we're here, let me ask about another test which isn't directly > > about unlock/lock but which is still somewhat related to this > > discussion: > > > > "MP+wmb+xchg-acq" (or some such) > > > > {} > > > > P0(int *x, int *y) > > { > > WRITE_ONCE(*x, 1); > > smp_wmb(); > > WRITE_ONCE(*y, 1); > > } > > > > P1(int *x, int *y) > > { > > r1 = atomic_xchg_relaxed(y, 2); > > r2 = smp_load_acquire(y); > > r3 = READ_ONCE(*x); > > } > > > > exists (1:r1=1 /\ 1:r2=2 /\ 1:r3=0) > > > > C/C++ would call the atomic_xchg_relaxed part of a release sequence > > and hence would forbid this outcome. > > That's just weird. Either its _relaxed, or its _release. Making _relaxed > mean _release is just daft.
I don't think it's actually that weird. If, for example, the write to *y in P0 was part of an UNLOCK operation and the load_acquire of y in P1 was a LOCK operation, then the xchg could just be setting some waiting bit in other bits of the lock word. C/C++ also requires order here if the xchg is done on its own thread. Will