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. -- 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/
