All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Jarek Poplawski <jarkao2@o2.pl>
Cc: linux-kernel@vger.kernel.org,
	"Robert P\. J\. Day" <rpjday@mindspring.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH (take 2)] Documentation/memory-barriers.txt: various fixes
Date: Tue, 22 May 2007 13:16:03 +0100	[thread overview]
Message-ID: <16186.1179836163@redhat.com> (raw)
In-Reply-To: <20070522061935.GA1639@ff.dom.local>

Jarek Poplawski <jarkao2@o2.pl> wrote:

> @@ -546,10 +546,10 @@
>  When dealing with CPU-CPU interactions, certain types of memory barrier should
>  always be paired.  A lack of appropriate pairing is almost certainly an error.
>  
> -A write barrier should always be paired with a data dependency barrier or read
> -barrier, though a general barrier would also be viable.  Similarly a read
> -barrier or a data dependency barrier should always be paired with at least an
> -write barrier, though, again, a general barrier is viable:
> +A write barrier should always be paired with a data dependency barrier or a
> +read barrier, though a general barrier would also be viable.  Similarly the
> +read barrier or the data dependency barrier should always be paired with at
> +least the write barrier, though, again, the general barrier is viable:

"A" not "the" please.

> @@ -1530,7 +1530,8 @@
>  If they're used for reference counting on an object to control its lifetime,
>  they probably don't need memory barriers because either the reference count
>  will be adjusted inside a locked section, or the caller will already hold
> -sufficient references to make the lock, and thus a memory barrier unnecessary.
> +sufficient references to make the lock, and thus the memory barrier
> +unnecessary.

Hmmm...  I'm wondering if that should actually by "a lock".

David

  reply	other threads:[~2007-05-22 12:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-21  9:42 [PATCH] Documentation/memory-barriers.txt: various fixes Jarek Poplawski
2007-05-21 12:09 ` David Howells
2007-05-21 13:50   ` Jarek Poplawski
2007-05-21 14:12     ` David Howells
2007-05-21 15:19       ` Jarek Poplawski
2007-05-22 13:39         ` Scott Preece
2007-05-22 14:19           ` Jarek Poplawski
2007-05-22  6:19       ` [PATCH (take 2)] " Jarek Poplawski
2007-05-22 12:16         ` David Howells [this message]
2007-05-22 13:35       ` [PATCH (take 3)] " Jarek Poplawski
2007-05-22 13:43         ` Jarek Poplawski
2007-05-22 14:03       ` [PATCH (take 4)] " Jarek Poplawski
2007-05-22 15:56         ` David Howells

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=16186.1179836163@redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jarkao2@o2.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpjday@mindspring.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.