Hi Manfred, On Thu, Sep 01, 2016 at 06:41:26PM +0200, Peter Zijlstra wrote: > On Thu, Sep 01, 2016 at 04:30:39PM +0100, Will Deacon wrote: > > On Thu, Sep 01, 2016 at 05:27:52PM +0200, Manfred Spraul wrote: > > > Since spin_unlock_wait() is defined as equivalent to spin_lock(); > > > spin_unlock(), the memory barrier before spin_unlock_wait() is > > > also not required. > As Peter said below, ACQUIRE+RELEASE is not a barrier. What we rely here is that spin_unlock_wait() could pair with another LOCK or UNLOCK(as spin_unlock_wait() acts as spin_lock(); spin_unlock()). And once paired, we could have the necessary order guarantee between the code preceding or following unlock_wait() and the code in the lock critical sections. Regards, Boqun > Note that ACQUIRE+RELEASE isn't a barrier. > > 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. > > RELEASE + ACQUIRE otoh, that is a load-store barrier (but not > transitive).
Attachment:
signature.asc
Description: PGP signature
