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

[Boqun Feng <boqun.feng@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Wed, Sep 16, 2015 at 05:38:14PM +0100, Will Deacon wrote:
> On Wed, Sep 16, 2015 at 12:49:18PM +0100, Boqun Feng wrote:
> > Hi Will,
> 
> Hello,
> 
> > On Tue, Sep 15, 2015 at 05:13:30PM +0100, Will Deacon wrote:
> > > +If necessary, ordering can be enforced by use of an
> > > +smp_mb__release_acquire() barrier:
> > > +
> > > +	*A = a;
> > > +	RELEASE M
> > > +	smp_mb__release_acquire();
> > 
> > Should this barrier be placed after the ACQUIRE? Because we do actually
> > want(?) and allow RELEASE and ACQUIRE operations to reorder in this
> > case, like your following example, right?
> 
> I think it's a lot simpler to keep it where it is, in all honesty. The
> relaxation for the RELEASE/ACQUIRE access ordering is mainly there to
> allow architectures building those operations out of explicit barriers
> to get away without a definition of smp_mb__release_acquire.
> 

Fair enough, and plus there is actually no user(even potential user) of
this for now, it may be too early to argue where the barrier should be
put.

Regards,
Boqun


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]