From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Oliver Neukum <oliver@neukum.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Uses for memory barriers
Date: Tue, 12 Sep 2006 07:42:04 -0700 [thread overview]
Message-ID: <20060912144204.GC1291@us.ibm.com> (raw)
In-Reply-To: <32145.1158051703@warthog.cambridge.redhat.com>
On Tue, Sep 12, 2006 at 10:01:43AM +0100, David Howells wrote:
> Paul E. McKenney <paulmck@us.ibm.com> wrote:
>
> > 2. All stores to a given single memory location will be perceived
> > as having occurred in the same order by all CPUs.
>
> Does that take into account a CPU combining or discarding coincident memory
> operations?
I believe so.
> For instance, a CPU asked to issue two writes to the same location may discard
> the first if it hasn't done it yet.
If I understand your example correctly, in that case, all CPUs would agree
that the given CPU's stores happened consecutively. Yes, they might not
see the intermediate value, but their view of the sequence of values
would be consistent with the given CPU's pair of stores having happened
at a specific place in the sequence of values.
This is not peculiar to this situation -- consider the following:
CPU 0 CPU 1 CPU 2 CPU 3
A=1
Q1=A Q3=A
A=2
A=3
Q2=A Q4=A
None of the CPUs saw CPU 2's first assignment A=2, but all of their
reads are consistent with the 1,2,3 sequence of values. Your example
(if I understand it correctly) is simply a special case where the
pair of assignments happened on a single CPU.
Thanx, Paul
next prev parent reply other threads:[~2006-09-12 14:41 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200609082230.22225.oliver@neukum.org>
2006-09-08 21:26 ` Uses for memory barriers Alan Stern
2006-09-08 21:46 ` Oliver Neukum
2006-09-08 22:25 ` Alan Stern
2006-09-08 22:49 ` Oliver Neukum
2006-09-09 2:25 ` Alan Stern
2006-09-11 16:21 ` Paul E. McKenney
2006-09-11 16:50 ` Alan Stern
2006-09-11 17:23 ` Segher Boessenkool
2006-09-11 19:04 ` Paul E. McKenney
2006-09-11 19:03 ` Paul E. McKenney
2006-09-11 17:21 ` Segher Boessenkool
2006-09-11 19:48 ` Oliver Neukum
2006-09-11 20:29 ` Paul E. McKenney
2006-09-12 9:01 ` David Howells
2006-09-12 10:22 ` Oliver Neukum
2006-09-12 14:55 ` Paul E. McKenney
2006-09-12 15:07 ` Oliver Neukum
2006-09-12 16:12 ` Paul E. McKenney
2006-09-12 17:50 ` Segher Boessenkool
2006-09-12 14:42 ` Paul E. McKenney [this message]
2006-09-12 8:57 ` David Howells
[not found] <20060911190005.GA1295@us.ibm.com>
2006-09-12 18:08 ` Alan Stern
2006-09-12 20:23 ` Paul E. McKenney
2006-09-14 14:58 ` Alan Stern
2006-09-15 5:16 ` Paul E. McKenney
2006-09-15 19:48 ` Alan Stern
2006-09-16 4:19 ` Paul E. McKenney
2006-09-16 15:28 ` Alan Stern
2006-09-18 19:13 ` Paul E. McKenney
2006-09-18 20:13 ` Alan Stern
2006-09-19 0:47 ` Paul E. McKenney
2006-09-19 16:04 ` Alan Stern
2006-09-19 16:38 ` Nick Piggin
2006-09-19 17:40 ` Alan Stern
2006-09-19 17:51 ` Nick Piggin
2006-09-19 18:19 ` Paul E. McKenney
2006-09-19 18:48 ` Nick Piggin
2006-09-19 19:36 ` Paul E. McKenney
2006-09-19 19:48 ` Nick Piggin
2006-09-19 20:01 ` Paul E. McKenney
2006-09-19 20:38 ` Alan Stern
2006-09-21 1:43 ` Paul E. McKenney
2006-09-19 18:16 ` Paul E. McKenney
2006-09-20 19:39 ` Alan Stern
2006-09-21 1:34 ` Paul E. McKenney
2006-09-21 20:59 ` Alan Stern
2006-09-22 5:02 ` Paul E. McKenney
2006-09-22 20:38 ` Alan Stern
2006-09-27 21:06 ` Alan Stern
2006-09-30 1:11 ` Paul E. McKenney
2006-09-30 21:01 ` Alan Stern
2006-10-02 0:06 ` Paul E. McKenney
2006-10-02 15:44 ` Alan Stern
2006-10-04 15:35 ` Paul E. McKenney
2006-10-04 18:04 ` Alan Stern
2006-10-13 16:51 ` Paul E. McKenney
2006-10-13 18:30 ` Alan Stern
2006-10-13 22:39 ` Paul E. McKenney
2006-10-14 2:27 ` Alan Stern
2006-10-17 1:24 ` Paul E. McKenney
2006-10-17 15:29 ` Alan Stern
2006-10-17 17:27 ` Paul E. McKenney
2006-10-17 19:42 ` Alan Stern
2006-10-17 20:15 ` Paul E. McKenney
2006-10-17 21:21 ` Alan Stern
2006-10-17 22:58 ` Paul E. McKenney
2006-10-18 19:05 ` Alan Stern
2006-10-18 23:01 ` Paul E. McKenney
2006-10-19 16:44 ` Alan Stern
2006-10-19 19:21 ` Paul E. McKenney
2006-10-19 20:55 ` Alan Stern
2006-10-19 22:46 ` Paul E. McKenney
2006-10-20 16:54 ` Alan Stern
2006-10-21 0:59 ` Paul E. McKenney
2006-10-21 19:47 ` Alan Stern
2006-10-21 22:52 ` Paul E. McKenney
2006-10-22 2:18 ` Alan Stern
2006-10-23 5:32 ` Paul E. McKenney
2006-10-23 14:07 ` Alan Stern
2006-10-24 17:52 ` Paul E. McKenney
[not found] <200609081929.33027.oliver@neukum.org>
2006-09-08 18:06 ` Alan Stern
2006-09-08 18:22 ` Oliver Neukum
2006-09-07 21:25 Alan Stern
2006-09-07 22:10 ` linux-os (Dick Johnson)
2006-09-08 18:39 ` Alan Stern
2006-09-08 0:14 ` Paul E. McKenney
2006-09-08 15:55 ` Alan Stern
2006-09-08 18:57 ` Paul E. McKenney
2006-09-08 21:23 ` Alan Stern
2006-09-09 0:44 ` Paul E. McKenney
2006-09-11 16:05 ` Alan Stern
2006-09-08 5:52 ` David Schwartz
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=20060912144204.GC1291@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver@neukum.org \
--cc=stern@rowland.harvard.edu \
/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.