Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()

[Will Deacon <will.deacon@arm.com>]

On Mon, Jul 13, 2015 at 04:54:47PM +0100, Peter Zijlstra wrote:
> However I think we should look at the insides of the critical sections;
> for example (from Documentation/memory-barriers.txt):
> 
> "       *A = a;
>         RELEASE M
>         ACQUIRE N
>         *B = b;
> 
> could occur as:
> 
>         ACQUIRE N, STORE *B, STORE *A, RELEASE M"
> 
> This could not in fact happen, even though we could flip M and N, A and
> B will remain strongly ordered.
> 
> That said, I don't think this could even happen on PPC because we have
> load_acquire and store_release, this means that:
> 
> 	*A = a
> 	lwsync
> 	store_release M
> 	load_acquire N
> 	lwsync
> 	*B = b
> 
> And since the store to M is wrapped inside two lwsync there must be
> strong store order, and because the load from N is equally wrapped in
> two lwsyncs there must also be strong load order.
> 
> In fact, no store/load can cross from before the first lwsync to after
> the latter and the other way around.
> 
> So in that respect it does provide full load-store ordering. What it
> does not provide is order for M and N, nor does it provide transitivity,
> but looking at our documentation I'm not at all sure we guarantee that
> in any case.

So if I'm following along, smp_mb__after_unlock_lock *does* provide
transitivity when used with UNLOCK + LOCK, which is stronger than your
example here.

I don't think we want to make the same guarantee for general RELEASE +
ACQUIRE, because we'd end up forcing most architectures to implement the
expensive macro for a case that currently has no users.

In which case, it boils down to the question of how expensive it would
be to implement an SC UNLOCK operation on PowerPC and whether that justifies
the existence of a complicated barrier macro that isn't used outside of
RCU.

Will