Re: [PATCH v2 RFC 1/3] documentation: Add needed ACCESS_ONCE() calls to memory-barriers.txt

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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