From: Keith Owens <kaos@ocs.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory Barrier Definitions
Date: Thu, 09 May 2002 18:01:37 +1000 [thread overview]
Message-ID: <17895.1020931297@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Thu, 09 May 2002 17:36:46 +1000." <20020509173646.5c1b5baa.rusty@rustcorp.com.au>
On Thu, 9 May 2002 17:36:46 +1000,
Rusty Russell <rusty@rustcorp.com.au> wrote:
>Hmmm... could you explain more? You're saying that every load is
>an "acquire" and every store a "release"? Or that they can be flagged
>that way, but aren't always?
cc trimmed.
The IA64 default is unordered memory accesses, except for special
instructions. From Intel IA-64 Architecture Software Developer's
Manual. Volume 1: IA-64 Application Architecture.
4.4.7 Memory Access Ordering
Memory data access ordering must satisfy read-after-write (RAW),
write-after-write (WAW), and write-after-read (WAR) data dependencies
to the same memory location. In addition, memory writes and flushes
must observe control dependencies. Except for these restrictions,
reads, writes, and flushes may occur in an order different from the
specified program order. Note that no ordering exists between
instruction accesses and data accesses or between any two instruction
accesses. The mechanisms described below are defined to enforce a
particular memory access order. In the following discussion, the terms
"previous" and "subsequent" are used to refer to the program specified
order. The term "visible" is used to refer to all architecturally
visible effects of performing a memory access (at a minimum this
involves reading or writing memory).
Memory accesses follow one of four memory ordering semantics:
unordered, release, acquire or fence. Unordered data accesses may
become visible in any order. Release data accesses guarantee that all
previous data accesses are made visible prior to being made visible
themselves. Acquire data accesses guarantee that they are made visible
prior to all subsequent data accesses. Fence operations combine the
release and acquire semantics into a bi-directional fence, i.e. they
guarantee that all previous data accesses are made visible prior to any
subsequent data accesses being made visible.
Explicit memory ordering takes the form of a set of instructions:
ordered load and ordered check load (ld.acq, ld.c.clr.acq), ordered
store (st.rel), semaphores (cmpxchg, xchg, fetchadd), and memory fence
(mf). The ld.acq and ld.c.clr.acq instructions follow acquire
semantics. The st.rel follows release semantics. The mf instruction is
a fence operation. The xchg, fetchadd.acq, and cmpxchg.acq instructions
have acquire semantics. The cmpxchg.rel, and fetchadd.rel instructions
have release semantics. The semaphore instructions also have implicit
ordering. If there is a write, it will always follow the read. In
addition, the read and write will be performed atomically with no
intervening accesses to the same memory region.
next prev parent reply other threads:[~2002-05-09 8:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-07 19:07 Memory Barrier Definitions Dave Engebretsen
2002-05-07 19:49 ` Alan Cox
2002-05-07 19:53 ` Dave Engebretsen
2002-05-07 20:27 ` Alan Cox
2002-05-07 21:23 ` Dave Engebretsen
2002-05-07 22:15 ` justincarlson
2002-05-08 2:49 ` Dave Engebretsen
2002-05-08 13:54 ` Justin Carlson
2002-05-08 15:27 ` Dave Engebretsen
2002-05-08 15:49 ` Andi Kleen
2002-05-08 17:07 ` David Mosberger
2002-05-09 7:36 ` Rusty Russell
2002-05-09 8:01 ` Keith Owens [this message]
2002-05-09 15:00 ` David Mosberger
2002-05-13 3:26 ` Rusty Russell
2002-05-13 16:36 ` David Mosberger
2002-05-13 16:50 ` Linus Torvalds
2002-05-13 17:53 ` David Mosberger
2002-05-13 23:28 ` Rusty Russell
2002-05-07 22:57 ` Anton Blanchard
2002-05-13 18:16 ` Jesse Barnes
-- strict thread matches above, loose matches on Subject: below --
2002-05-09 11:33 Manfred Spraul
2002-05-09 19:38 ` Dave Engebretsen
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=17895.1020931297@kao2.melbourne.sgi.com \
--to=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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