Messages in this thread | | | Date | Wed, 16 Sep 2015 17:38:14 +0100 | From | Will Deacon <> | Subject | Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation |
| |
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.
Will
| |