Re: [PATCH tip/core/rcu 3/4] documentation: Add acquire/release barriers to pairing rules
From: Paul E. McKenney
Date: Tue Jul 08 2014 - 11:31:30 EST
On Tue, Jul 08, 2014 at 09:59:02AM +0200, Peter Zijlstra wrote:
> On Mon, Jul 07, 2014 at 03:24:21PM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
> > It is possible to pair acquire and release barriers with other barriers,
> > so this commit adds them to the list in the SMP barrier pairing section.
> > Reported-by: Lai Jiangshan <laijs@xxxxxxxxxxxxxx>
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> > Reviewed-by: Tejun Heo <tj@xxxxxxxxxx>
> > +A write barrier should always be paired with a data dependency barrier,
> > +acquire barrier, release barrier, or read barrier, though a general
> > +barrier would also be viable.
> Similarly a read barrier or a data
> > +dependency barrier should always be paired with at least a write barrier,
> > +an acquire barrier, or a release barrier, though, again, a general
> > +barrier is viable:
> When I first read the Changelog I though you were going to add things
> An acquire barrier should be paired with a release barrier, however
> .... barrier is also viable.
> A release barrier should be paired with an acquire barrier,... etc.
> Now the above does seem to imply such rules but it isn't explicit in
> them, since it only lists the requirements for read/write. Now since the
> entire thing is indeed symmetric the implications are fairly strong,
Good point, how about the following?
General barriers pair with each other, though they also pair
with most other types of barriers, albeit without transitivity.
An acquire barrier pairs with a release barrier, but both may also
pair with other barriers, including of course general barriers.
A write barrier pairs with a data dependency barrier, an acquire
barrier, a release barrier, a read barrier, or a general barrier.
Similarly a read barrier or a data dependency barrier pairs
with a write barrier, an acquire barrier, a release barrier,
or a general barrier:
> Also, it might be good to have a section on the ramifications of pairing
> acquire/release with other than themselves, I have the feeling there's
> subtle things there.
It can get quite subtle. For the time being, I am dodging this subtlety
by saying that only general barriers provide transitivity (see the
To give but one example of the subtlety, given X, Y, and Z all initially
zero where it matters:
X=2; Y=2; Z=2;
smp_wmb(); smp_wmb(); smp_wmb();
Y=1; Z=1; X=1;
BUG_ON(X==2 && Y==2 && Z==2); /* Never triggers. */
X=2; Y=2; Z=2;
smp_wmb(); smp_wmb(); smp_mb();
Y=1; Z=1; r1=X;
BUG_ON(r1==0 && Y==2 && Z==2); /* Can trigger!!! */
Maybe some day we should capture this subtlety in memory-barriers.txt,
but we will first need a new generation of small children who are not
scared by the current document. ;-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/