Messages in this thread | | | Date | Thu, 1 Sep 2016 13:51:34 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 1/4] spinlock: Document memory barrier rules |
| |
On Thu, Sep 01, 2016 at 01:04:26PM +0200, Manfred Spraul wrote:
> >So for both power and arm64, you can in fact model spin_unlock_wait() > >as LOCK+UNLOCK.
> Is this consensus?
Dunno, but it was done to fix your earlier locking scheme and both architectures where it matters have done so.
So I suppose that could be taken as consensus ;-)
> If I understand it right, the rules are: > 1. spin_unlock_wait() must behave like spin_lock();spin_unlock();
From a barrier perspective, yes I think so. Ideally the implementation would avoid stores (which was the entire point of introducing that primitive IIRC) if at all possible (not possible on ARM64/Power).
> 2. spin_is_locked() must behave like spin_trylock() ? spin_unlock(),TRUE : > FALSE
Not sure on this one, That might be consistent, but I don't see the ll/sc-nop in there. Will?
> 3. the ACQUIRE during spin_lock applies to the lock load, not to the store.
I think we can state that ACQUIRE on _any_ atomic only applies to the LOAD not the STORE.
And we're waiting for that to bite us again before trying to deal with it in a more generic manner; for now only the spinlock implementations (specifically spin_unlock_wait) deal with it.
Will, Boqun, did I get that right?
| |