Messages in this thread | | | Date | Fri, 9 Oct 2015 13:02:46 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation |
| |
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote: > Stepping back a second, I believe that there are three cases: > > > RELEASE X -> ACQUIRE Y (same CPU) > * Needs a barrier on TSO architectures for full ordering +PPC
> UNLOCK X -> LOCK Y (same CPU) > * Needs a barrier on PPC for full ordering
> RELEASE X -> ACQUIRE X (different CPUs) * Fully ordered everywhere... * ... but needs a barrier on TSO + PPC to become a full barrier
> UNLOCK X -> ACQUIRE X (different CPUs)
s/ACQUIRE/LOCK/ ?
> * Fully ordered everywhere... > * ... but needs a barrier on PPC to become a full barrier
If you really meant ACQUIRE, then x86 also needs a barrier in order to upgrade, seeing how our unlock is equivalent to smp_store_release(). Our LOCK otoh is far heavier than smp_load_acquire() and would result in different rules.
And I'm not sure the "(different CPUs)" bit makes sense, as the same is true if they're on the same CPU.
| |