Messages in this thread | | | Date | Thu, 17 Sep 2015 09:56:14 +0800 | From | Boqun Feng <> | Subject | Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation |
| |
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
[unhandled content-type:application/pgp-signature] | |