On Wed, Aug 13, 2014 at 8:35 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: >> >> If the stores to 'b' differ, then there is no issue. Why not document how to >> avoid re-ordering in the case where both the stores are the same? In that >> case >> using a stronger barrier like mb() should be sufficient for both the compiler >> and the CPU to avoid re-ordering, right? > > Like this? (On top of the earlier patch.) >
That looks good, thank you! > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/Documentation/memory-barriers.txt > b/Documentation/memory-barriers.txt > index 6062f175abc6..22a969cdd476 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -625,9 +625,20 @@ Now there is no conditional between the load from 'a' > and the store to > 'b', which means that the CPU is within its rights to reorder them: > The conditional is absolutely required, and must be present in the > assembly code even after all compiler optimizations have been applied. > +Therefore, if you need ordering in this example, you need explicit > +memory barriers, for example, smp_store_release(): > > -So two-legged-if control ordering is guaranteed only when the stores > -differ, for example: > + q = ACCESS_ONCE(a); > + if (q) { > + smp_store_release(&b, p); > + do_something(); > + } else { > + smp_store_release(&b, p); > + do_something_else(); > + } > + > +In contrast, without explicit memory barriers, two-legged-if control > +ordering is guaranteed only when the stores differ, for example: > > q = ACCESS_ONCE(a); > if (q) { > -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/