On Sat, Nov 23, 2013 at 10:04:06AM +0100, Peter Zijlstra wrote: > On Fri, Nov 22, 2013 at 10:13:13AM -0800, Paul E. McKenney wrote: > > How about the following? > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > COMPILER BARRIER > > ---------------- > > > > The Linux kernel has an explicit compiler barrier function that prevents the > > compiler from moving the memory accesses either side of it to the other > > side: > > > > barrier(); > > > > This is a general barrier -- there are no read-read or write-write variants > > of barrier(). Howevever, ACCESS_ONCE() can be thought of as a weak form > > for barrier() that affects only the specific accesses flagged by the > > ACCESS_ONCE(). > > > > The compiler barrier has no direct effect on the CPU, which may then reorder > > things however it wishes. > > > > Seems ok, however this also seems like the natural spot to put that > chunk about how a compiler can mis-transform stuff without either > barrier or ACCESS_ONC(); that currently seems spread out over the > document in some notes. > > The biggest of which seems to have ended up in the GUARANTEES chapter.
Good point! I believe that the spread-out stuff is still needed, so I will add a summary of that information here, perhaps based in part on Jon Corbet's ACCESS_ONCE() article (http://lwn.net/Articles/508991/). Seem reasonable? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
