On Fri, Sep 02, 2016 at 08:35:55AM +0200, Manfred Spraul wrote:For me, it doesn't really matter.
On 09/01/2016 06:41 PM, Peter Zijlstra wrote:Correct, sadly implementations do not comply :/ In fact, even x86 is
On Thu, Sep 01, 2016 at 04:30:39PM +0100, Will Deacon wrote:CPU1:
On Thu, Sep 01, 2016 at 05:27:52PM +0200, Manfred Spraul wrote:Note that ACQUIRE+RELEASE isn't a barrier.
Since spin_unlock_wait() is defined as equivalent to spin_lock();
spin_unlock(), the memory barrier before spin_unlock_wait() is
also not required.
Both are semi-permeable and things can cross in the middle, like:
x = 1;
LOCK
UNLOCK
r = y;
can (validly) get re-ordered like:
LOCK
r = y;
x = 1;
UNLOCK
So if you want things ordered, as I think you do, I think the smp_mb()
is still needed.
x=1; /* without WRITE_ONCE */
LOCK(l);
UNLOCK(l);
<do_semop>
smp_store_release(x,0)
CPU2;
LOCK(l)
if (smp_load_acquire(x)==1) goto slow_path
<do_semop>
UNLOCK(l)
Ordering is enforced because both CPUs access the same lock.
x=1 can't be reordered past the UNLOCK(l), I don't see that further
guarantees are necessary.
Correct?
broken here.
I spoke to Will earlier today and he suggests either making
spin_unlock_wait() stronger to avoids any and all such surprises or just
getting rid of the thing.
I'm not sure which way we should go, but please hold off on these two
patches until I've had a chance to audit all of those implementations
again.