lkml.org 
[lkml]   [2006]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Document Linux's memory barriers [try #5]
Hello,
This is just a question about intended meaning in a paragraph
at the end of the "What are memory barriers?" section.

> From: Paul E. McKenney Thu Mar 16 2006 - 18:14:11 EST
> On Wed, Mar 15, 2006 at 02:23:19PM +0000, David Howells wrote:
> >
> > The attached patch documents the Linux kernel's memory barriers.
> >
> > I've updated it from the comments I've been given.
> >
> . . .
>
> Good stuff!!! Please see comments interspersed, search for empty lines.
>
> One particularly serious issue involve your smp_read_barrier_depends()
> example.
>
> > Signed-Off-By: David Howells <dhowells@redhat.com>
> > ---
> > warthog>diffstat -p1 /tmp/mb.diff
> > Documentation/memory-barriers.txt | 1039
> ++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 1039 insertions(+)
> >
> > diff --git a/Documentation/memory-barriers.txt
> b/Documentation/memory-barriers.txt
> > new file mode 100644
> > index 0000000..fd7a6f1
> > --- /dev/null
> > +++ b/Documentation/memory-barriers.txt
> > @@ -0,0 +1,1039 @@
> > + ============================
> > + LINUX KERNEL MEMORY BARRIERS
> > + ============================

. . .

> > +=========================
> > +WHAT ARE MEMORY BARRIERS?
> > +=========================
> > +

> . . .

> > +It is also guaranteed that a CPU will be self-consistent: it will see its _own_
> > +accesses appear to be correctly ordered, without the need for a memory barrier.
> > +For instance with the following code:
> > +
> > + X = *A;
> > + *A = Y;
> > + Z = *A;
> > +
> > +assuming no intervention by an external influence, it can be taken that:
> > +
> > + (*) X will hold the old value of *A, and will never happen after the write and
> > + thus end up being given the value that was assigned to *A from Y instead;

Seems like the subject of "will never happen" is the read from memory for the
asmt to X, but does that sentence say that?

> > + and
> > +
> > + (*) Z will always be given the value in *A that was assigned there from Y, and
> > + will never happen before the write, and thus end up with the same value
> > + that was in *A initially.

Similarly, the read from memory for the asmt to Z won't precede the write of Y
to *A.

> > +
> > +(This is ignoring the fact that the value initially in *A may appear to be the
> > +same as the value assigned to *A from Y).
> > +
> > +
> > +=================================
> > +WHERE ARE MEMORY BARRIERS NEEDED?
> > +=================================

It seems to require more effort than necessary to understand in regard to
all that is presented in this document.

Thanks.
Suzanne
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-29 00:28    [W:0.053 / U:1.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site