public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com
Cc: stern@rowland.harvard.edu, j.alglave@ucl.ac.uk,
	luc.maranget@inria.fr, parri.andrea@gmail.com,
	will.deacon@arm.com, linux-alpha@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Question about DEC Alpha memory ordering
Date: Mon, 13 Feb 2017 10:39:20 -0800	[thread overview]
Message-ID: <20170213183920.GA25191@linux.vnet.ibm.com> (raw)

Hello!

We have a question about DEC Alpha memory ordering.  Given the litmus test
shown at the end of this email, some of us believe that DEC Alpha won't
ever have both P0()'s and P1()'s READ_ONCE() calls return 1, but others
believe otherwise.  Our current Linux-kernel memory model assumes that
it cannot, though we are not aware of any Linux-kernel code that cares.

In this litmus test, the "C auto/C-LB-LRW+OB-Ov" and the empty pair
of curly braces can be ignored.  P0() and P1() run concurrently, and
are passed pointer to the two shared variables that they are accessing
(u0 and x1, and yes, this test was automatically generated -- why do
you ask?).  The "exists" clause at the end is evaluated at the end of
time, after all the dust has settled.  Note that the undeclared "r1"
variables are local to their respective functions, and that "0:r1" in
the "exists" clause accesses P0()'s instance of "r1", and that "1:r1"
similarly accesses P1()'s "r1".

So, can real DEC Alpha hardware end up with both instances of "r1"
having the value 1?

							Thanx, Paul

------------------------------------------------------------------------

C auto/C-LB-LRW+OB-Ov
{
}

P0(int *u0, int *x1)
{
	r1 = READ_ONCE(*u0);
	smp_mb();
	WRITE_ONCE(*x1, 1);
}


P1(int *u0, int *x1)
{
	r1 = READ_ONCE(*x1);
	WRITE_ONCE(*u0, r1);
}

exists
(0:r1=1 /\ 1:r1=1)

             reply	other threads:[~2017-02-13 18:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 18:39 Paul E. McKenney [this message]
2017-02-13 18:53 ` Question about DEC Alpha memory ordering bob smith
2017-02-13 19:08   ` Will Deacon
2017-02-13 19:09   ` Paul E. McKenney
2017-02-13 19:14     ` Tobias Klausmann
2017-02-13 20:28       ` Paul E. McKenney
2017-02-13 21:06         ` Alan Stern
2017-02-13 21:24           ` Paul E. McKenney
2017-02-14 11:35             ` Andrea Parri
2017-02-14 19:26               ` Michael Cree
2017-02-14 20:12                 ` Andrea Parri
2017-02-13 19:23     ` Michael Cree
2017-02-13 20:32       ` 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=20170213183920.GA25191@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=mattst88@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=rth@twiddle.net \
    --cc=stern@rowland.harvard.edu \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox