On Fri, Nov 22, 2013 at 04:39:08PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 21, 2013 at 01:31:27PM -0800, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <[email protected]>
> >
> > The Documentation/memory-barriers.txt file was written before the need
> > for ACCESS_ONCE() was fully appreciated. It therefore contains no
> > ACCESS_ONCE() calls, which can be a problem when people lift examples
> > from it. This commit therefore adds ACCESS_ONCE() calls.
> >
>
> Under the 'COMPILER BARRIER' section we state that:
>
> "This is a general barrier - lesser varieties of compiler barrier do not
> exist."
>
> One could argue ACCESS_ONCE() is such a lesser barrier.
Fair point -- I should have updated this section when adding ACCESS_ONCE().
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.
--
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/
