From: Rusty Russell <rusty@rustcorp.com.au>
To: Richard Henderson <rth@twiddle.net>
Cc: pmckenne@us.ibm.com, lse-tech@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: RFC: patch to allow lock-free traversal of lists with insertion
Date: Tue, 9 Oct 2001 19:03:37 +1000 [thread overview]
Message-ID: <20011009190337.0009802c.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20011008235208.A26109@twiddle.net>
In-Reply-To: <200110090155.f991tPt22329@eng4.beaverton.ibm.com> <20011008235208.A26109@twiddle.net>
On Mon, 8 Oct 2001 23:52:08 -0700
Richard Henderson <rth@twiddle.net> wrote:
> On Mon, Oct 08, 2001 at 06:55:24PM -0700, Paul E. McKenney wrote:
> > This is a proposal to provide a wmb()-like primitive that enables
> > lock-free traversal of lists while elements are concurrently being
> > inserted into these lists.
>
> I've discussed this with you before and you continue to have
> completely missed the point.
>
> Alpha requires that you issue read-after-read memory barriers on
> the reader side if you require ordering between reads. That is
> the extent of the weakness of the memory ordering.
Actually, I think you are missing the point. On most architectures, a
writer can do:
int *global_ptr = NULL;
x = 1;
wmb();
global_ptr = &x;
And a reader can rely on the dereference as an implicit read barrier:
if (global_ptr) {
if (*global_ptr != 1)
BUG();
}
This is *not guarenteed* on the Alpha. To quote an earlier offline mail
from Paul McKenney (cc'd to you):
> The case that they said can cause trouble is if the CPU 1's caches are
> partitioned. In such cases, the partitions of the cache run pretty much
> independently. If "p" is in a cacheline handled by one partition, and
> "*p" is in a cacheline handled by the other partition, it is possible
> for the invalidation of "p" (due to the "p = &a") to get processed before
> the invalidation of "*p" (which is just "a", due to the "a = 1").
Now, expecting every piece of code to insert an rmb() before dereferencing
a pointer in these cases, just so Alphas don't fail occasionally is NOT a
good solution. Inventing a "rmb_me_harder()" macro for Alpha only is pretty
horrible too. I don't *like* making Alpha's wmb() stronger, but it is the
only solution which doesn't touch common code.
Of course, we can continue to ignore it, which is my preferred solution.
Hope that helps,
Rusty.
PS. This was used by Alan Cox for lock-free insertion into the firewall linked
list in 2.0 - 2.2, and will become more common.
next prev parent reply other threads:[~2001-10-09 9:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-09 1:55 RFC: patch to allow lock-free traversal of lists with insertion Paul E. McKenney
2001-10-09 2:18 ` David S. Miller
2001-10-09 6:52 ` Richard Henderson
2001-10-09 9:03 ` Rusty Russell [this message]
2001-10-09 16:11 ` Richard Henderson
2001-10-10 1:39 ` Rusty Russell
2001-10-09 7:13 ` BALBIR SINGH
2001-10-09 7:46 ` Dipankar Sarma
2001-10-09 8:21 ` BALBIR SINGH
2001-10-09 8:48 ` Dipankar Sarma
-- strict thread matches above, loose matches on Subject: below --
2001-10-09 5:27 Paul McKenney
2001-10-09 5:56 ` David S. Miller
2001-10-09 6:43 ` Richard Henderson
2001-10-09 15:24 Paul McKenney
2001-10-09 15:28 Paul McKenney
2001-10-09 15:45 Paul McKenney
2001-10-09 17:00 ` Richard Henderson
2001-10-10 3:33 ` Paul Mackerras
2001-10-10 17:02 ` Richard Henderson
2001-10-09 16:51 Manfred Spraul
2001-10-09 17:46 Paul McKenney
2001-10-09 18:01 Paul McKenney
2001-10-10 1:19 Paul McKenney
2001-10-10 1:43 ` Andrea Arcangeli
2001-10-10 21:47 Paul McKenney
2001-10-10 22:22 ` Richard Henderson
2001-10-10 22:27 ` Richard Henderson
2001-10-11 1:56 Paul E. McKenney
2001-10-12 4:14 ` Rusty Russell
2001-10-13 14:48 ` Paul E. McKenney
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=20011009190337.0009802c.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=pmckenne@us.ibm.com \
--cc=rth@twiddle.net \
/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