All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Question about memory barriers
Date: Thu, 02 Feb 2006 13:37:48 -0800	[thread overview]
Message-ID: <adamzh9xx03.fsf@cisco.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0602021607100.5016-100000@iolanthe.rowland.org> (Alan Stern's message of "Thu, 2 Feb 2006 16:12:16 -0500 (EST)")

>>>>> "Alan" == Alan Stern <stern@rowland.harvard.edu> writes:

    Alan> The kernel's documentation about memory barriers is rather
    Alan> skimpy.  I gather that rmb() guarantees that all preceding
    Alan> reads will have completed before any following reads are
    Alan> made, and wmb() guarantees that all preceding writes will
    Alan> have completed before any following writes are made.  I also
    Alan> gather that mb() is essentially the same as rmb() and wmb()
    Alan> put together.

Most of this is correct, except that mb() is stronger than just rmb()
and wmb() put together.  All memory operations before the mb() will
complete before any operations after the mb().  A better way to
understand this is to look at the sparc64 definition:

#define mb()    \
        membar_safe("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad")

    Alan> But suppose I need to prevent a read from being moved past a
    Alan> write?  It doesn't look like either rmb() or wmb() will do
    Alan> this.  And if mb() is the same as "rmb(); wmb();" then it
    Alan> won't either.  So what's the right thing to do?

As described above, mb() will work in this case.  It actually
guarantees more than you need, so you could conceivably define a new
primitive, but the current barriers are hard enough for people to
figure out ;)

 - R.

  parent reply	other threads:[~2006-02-02 21:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-02 21:12 Question about memory barriers Alan Stern
2006-02-02 21:32 ` linux-os (Dick Johnson)
2006-02-02 21:37 ` Roland Dreier [this message]
2006-02-02 21:49   ` Alan Stern
2006-02-02 21:52     ` Randy.Dunlap

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=adamzh9xx03.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=linux-kernel@vger.kernel.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.