From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: afzal mohammed <afzal.mohd.ma@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Peter Zijlstra <peterz@infradead.org>,
parri.andrea@gmail.com, will.deacon@arm.com,
boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com,
j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
linux-kernel@vger.kernel.org, elena.reshetova@intel.com
Subject: Re: Prototype patch for Linux-kernel memory model
Date: Wed, 20 Dec 2017 08:45:38 -0800 [thread overview]
Message-ID: <20171220164538.GL7829@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171220113145.GA5082@afzalpc>
On Wed, Dec 20, 2017 at 05:01:45PM +0530, afzal mohammed wrote:
> Hi,
>
> Is this patch not destined to the HEAD of Torvalds ?, got that feeling
> as this was in flight around merge window & have not yet made there.
That is the goal, hopefully the next merge window, or if not, the one
after that.
> On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:
>
> > diff --git a/tools/memory-model/Documentation/recipes.txt b/tools/memory-model/Documentation/recipes.txt
>
> > +Taking off the training wheels
> > +==============================
> :
> > +Release-acquire chains
> > +----------------------
> :
> > +It is tempting to assume that CPU0()'s store to x is globally ordered
> > +before CPU1()'s store to z, but this is not the case:
> > +
> > + /* See Z6.0+pooncerelease+poacquirerelease+mbonceonce.litmus. */
> > + void CPU0(void)
> > + {
> > + WRITE_ONCE(x, 1);
> > + smp_store_release(&y, 1);
> > + }
> > +
> > + void CPU1(void)
> > + {
> > + r1 = smp_load_acquire(y);
> > + smp_store_release(&z, 1);
> > + }
> > +
> > + void CPU2(void)
> > + {
> > + WRITE_ONCE(z, 2);
> > + smp_mb();
> > + r2 = READ_ONCE(x);
> > + }
> > +
> > +One might hope that if the final value of r1 is 1 and the final value
> > +of z is 2, then the final value of r2 must also be 1, but the opposite
> > +outcome really is possible.
>
> As there are 3 variables to have the values, perhaps, it might be
> clearer to have instead of "the opposite.." - "the final value need
> not be 1" or was that a read between the lines left as an exercise to
> the idiots ;)
Heh! Good catch, thank you! How about the following for the paragraph
immediately after that litmus test?
One might hope that if the final value of r0 is 1 and the final
value of z is 2, then the final value of r1 must also be 1,
but it really is possible for r1 to have the final value of 0.
The reason, of course, is that in this version, CPU2() is not
part of the release-acquire chain. This situation is accounted
for in the rules of thumb below.
I also fixed r1 and r2 to match the names in the actual litmus test.
Thanx, Paul
> afzal
>
>
> > The reason, of course, is that in this
> > +version, CPU2() is not part of the release-acquire chain. This
> > +situation is accounted for in the rules of thumb below.
>
next prev parent reply other threads:[~2017-12-20 16:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-13 18:40 Prototype patch for Linux-kernel memory model Paul E. McKenney
2017-11-13 20:09 ` Alan Stern
2017-11-14 4:52 ` Paul E. McKenney
2017-11-14 7:59 ` Peter Zijlstra
2017-11-14 15:19 ` Alan Stern
2017-11-14 17:15 ` Paul E. McKenney
2017-11-15 16:37 ` Paul E. McKenney
2017-11-17 11:27 ` Boqun Feng
2017-11-20 16:35 ` Andrea Parri
2017-11-20 19:30 ` Paul E. McKenney
2017-12-19 8:36 ` afzal mohammed
2017-12-19 16:05 ` Alan Stern
2017-12-20 11:31 ` afzal mohammed
2017-12-20 16:45 ` Paul E. McKenney [this message]
2017-12-21 3:30 ` afzal mohammed
2017-12-21 16:15 ` Paul E. McKenney
2017-12-22 4:11 ` afzal mohammed
2017-12-23 6:14 ` afzal mohammed
2018-01-02 20:25 ` 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=20171220164538.GL7829@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=afzal.mohd.ma@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=elena.reshetova@intel.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).