lkml.org 
[lkml]   [2013]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2013-11-25 18:41    [W:2.073 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site