[PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation
Peter Zijlstra
peterz at infradead.org
Fri Oct 9 22:02:46 AEDT 2015
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.
More information about the Linuxppc-dev
mailing list