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?