From: Suzanne Wood <suzannew@cs.pdx.edu>
To: dhowells@redhat.com
Cc: linux-kernel@vger.kernel.org, paulmck@us.ibm.com
Subject: Re: [PATCH] Document Linux's memory barriers [try #5]
Date: Tue, 28 Mar 2006 14:25:06 -0800 (PST) [thread overview]
Message-ID: <200603282225.k2SMP6kb023905@baham.cs.pdx.edu> (raw)
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
next reply other threads:[~2006-03-28 22:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-28 22:25 Suzanne Wood [this message]
2006-03-29 17:54 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2006-03-31 16:16 Suzanne Wood
2006-03-31 0:55 Suzanne Wood
2006-03-31 14:51 ` David Howells
2006-03-29 20:51 Suzanne Wood
2006-03-30 20:18 ` David Howells
[not found] <20060315200956.4a9e2cb3.akpm@osdl.org>
2006-03-09 20:29 ` [PATCH] Document Linux's memory barriers [try #4] David Howells
2006-03-15 14:23 ` [PATCH] Document Linux's memory barriers [try #5] David Howells
2006-03-16 11:50 ` David Howells
2006-03-16 17:18 ` Linus Torvalds
2006-03-17 1:20 ` Nick Piggin
2006-03-16 23:17 ` Paul E. McKenney
2006-03-16 23:55 ` Linus Torvalds
2006-03-17 1:29 ` Paul E. McKenney
2006-03-17 5:32 ` Linus Torvalds
2006-03-17 6:23 ` Paul E. McKenney
2006-03-23 18:34 ` David Howells
2006-03-23 19:28 ` Linus Torvalds
2006-03-23 22:26 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200603282225.k2SMP6kb023905@baham.cs.pdx.edu \
--to=suzannew@cs.pdx.edu \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®