Subject: Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

From: Peter Zijlstra <[email-masked]>
Date: Fri, 9 Oct 2015 13:02:46 +0200

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.