Messages in this thread | | | Date | Sat, 23 Nov 2013 09:17:19 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH v2 RFC 1/3] documentation: Add needed ACCESS_ONCE() calls to memory-barriers.txt |
| |
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
| |