On Thu, Sep 01, 2016 at 01:51:34PM +0200, Peter Zijlstra wrote: > 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? >
My understanding is as Will stated, we don't provide this strong gaurantee for spin_is_locked(). The reason is mostly because all(?) uses of spin_is_locked() are not for correctness but for other purposes like debug output. > > 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. > I think the hope is that, with herd or other tools, and a formal order model, we can make more people understand this "counter-intuitive" behavior and help them write correct and efficient code ;-) > > Will, Boqun, did I get that right? > Yep ;-) Regards, Boqun
signature.asc
Description: PGP signature
