From: Peter Zijlstra <peterz@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: memory barrier question
Date: Thu, 16 Sep 2010 18:18:59 +0200 [thread overview]
Message-ID: <1284653939.2275.578.camel@laptop> (raw)
In-Reply-To: <3777.1284638136@redhat.com>
On Thu, 2010-09-16 at 12:55 +0100, David Howells wrote:
> If there's a lock+unlock between, then this counts as a full memory
> barrier
I though it was unlock+lock.
From memory-barriers.txt:
And a couple of implicit varieties:
(5) LOCK operations.
This acts as a one-way permeable barrier. It guarantees that all memory
operations after the LOCK operation will appear to happen after the LOCK
operation with respect to the other components of the system.
Memory operations that occur before a LOCK operation may appear to happen
after it completes.
A LOCK operation should almost always be paired with an UNLOCK operation.
(6) UNLOCK operations.
This also acts as a one-way permeable barrier. It guarantees that all
memory operations before the UNLOCK operation will appear to happen before
the UNLOCK operation with respect to the other components of the system.
Memory operations that occur after an UNLOCK operation may appear to
happen before it completes.
LOCK and UNLOCK operations are guaranteed to appear with respect to each
other strictly in the order specified.
The use of LOCK and UNLOCK operations generally precludes the need for
other sorts of memory barrier (but note the exceptions mentioned in the
subsection "MMIO write barrier").
Therefore:
A = 5
LOCK
UNLOCK
B = 6
May be observed as:
LOCK
B = 6
A = 5
UNLOCK
The sequence:
A = 5
UNLOCK
LOCK
B = 6
Is fully ordered.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: memory barrier question
Date: Thu, 16 Sep 2010 18:18:59 +0200 [thread overview]
Message-ID: <1284653939.2275.578.camel@laptop> (raw)
In-Reply-To: <3777.1284638136@redhat.com>
On Thu, 2010-09-16 at 12:55 +0100, David Howells wrote:
> If there's a lock+unlock between, then this counts as a full memory
> barrier
I though it was unlock+lock.
>From memory-barriers.txt:
And a couple of implicit varieties:
(5) LOCK operations.
This acts as a one-way permeable barrier. It guarantees that all memory
operations after the LOCK operation will appear to happen after the LOCK
operation with respect to the other components of the system.
Memory operations that occur before a LOCK operation may appear to happen
after it completes.
A LOCK operation should almost always be paired with an UNLOCK operation.
(6) UNLOCK operations.
This also acts as a one-way permeable barrier. It guarantees that all
memory operations before the UNLOCK operation will appear to happen before
the UNLOCK operation with respect to the other components of the system.
Memory operations that occur after an UNLOCK operation may appear to
happen before it completes.
LOCK and UNLOCK operations are guaranteed to appear with respect to each
other strictly in the order specified.
The use of LOCK and UNLOCK operations generally precludes the need for
other sorts of memory barrier (but note the exceptions mentioned in the
subsection "MMIO write barrier").
Therefore:
A = 5
LOCK
UNLOCK
B = 6
May be observed as:
LOCK
B = 6
A = 5
UNLOCK
The sequence:
A = 5
UNLOCK
LOCK
B = 6
Is fully ordered.
next prev parent reply other threads:[~2010-09-16 16:19 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 14:36 memory barrier question Miklos Szeredi
2010-09-15 19:12 ` Rafael J. Wysocki
2010-09-16 11:55 ` David Howells
2010-09-16 13:42 ` Miklos Szeredi
2010-09-16 13:42 ` Miklos Szeredi
2010-09-16 13:42 ` Miklos Szeredi
2010-09-16 14:30 ` David Howells
2010-09-16 15:03 ` Paul E. McKenney
2010-09-16 16:06 ` Miklos Szeredi
2010-09-16 16:37 ` Paul E. McKenney
2010-09-16 16:56 ` Miklos Szeredi
2010-09-16 17:09 ` James Bottomley
2010-09-16 17:17 ` Miklos Szeredi
2010-09-16 17:40 ` James Bottomley
2010-09-17 21:49 ` Benjamin Herrenschmidt
2010-09-17 23:12 ` Paul E. McKenney
2010-09-19 2:47 ` Benjamin Herrenschmidt
2010-09-19 15:26 ` Paul E. McKenney
2010-09-19 20:15 ` Miklos Szeredi
2010-09-19 21:59 ` Paul E. McKenney
2010-09-20 0:58 ` James Bottomley
2010-09-20 1:29 ` Paul E. McKenney
2010-09-20 16:01 ` Miklos Szeredi
2010-09-20 18:25 ` Paul E. McKenney
2010-09-20 18:25 ` Paul E. McKenney
2010-09-20 18:57 ` Paul E. McKenney
2010-09-20 20:26 ` Michael Cree
2010-09-20 20:40 ` Paul E. McKenney
2010-09-21 14:59 ` Paul E. McKenney
2010-09-22 18:41 ` Paul E. McKenney
2010-09-18 1:12 ` Alan Cox
2010-09-16 16:50 ` Jamie Lokier
2010-09-16 16:18 ` Peter Zijlstra [this message]
2010-09-16 16:18 ` Peter Zijlstra
2010-09-16 17:59 ` David Howells
-- strict thread matches above, loose matches on Subject: below --
2010-09-20 10:34 George Spelvin
2010-10-29 13:23 Memory " Tetsuo Handa
2010-10-29 15:09 ` Paul E. McKenney
2010-10-30 5:48 ` Tetsuo Handa
2010-10-30 6:11 ` Eric Dumazet
2010-10-30 12:40 ` Tetsuo Handa
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=1284653939.2275.578.camel@laptop \
--to=peterz@infradead.org \
--cc=dhowells@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=paulmck@linux.vnet.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 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.