public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: afzal mohammed <afzal.mohd.ma@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.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: Tue, 19 Dec 2017 14:06:50 +0530	[thread overview]
Message-ID: <20171219083650.GA10215@afzalpc> (raw)
In-Reply-To: <20171115163749.GA8555@linux.vnet.ibm.com>

Hi,

A trivial & late (sorry) comment,

On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:

> +THE HAPPENS-BEFORE RELATION: hb
> +-------------------------------

> +Less trivial examples of prop all involve fences.  Unlike the simple
> +examples above, they can require that some instructions are executed
> +out of program order.  This next one should look familiar:
> +
> +	int buf = 0, flag = 0;
> +
> +	P0()
> +	{
> +		WRITE_ONCE(buf, 1);
> +		smp_wmb();
> +		WRITE_ONCE(flag, 1);
> +	}
> +
> +	P1()
> +	{
> +		int r1;
> +		int r2;
> +
> +		r1 = READ_ONCE(flag);
> +		r2 = READ_ONCE(buf);
> +	}
> +
> +This is the MP pattern again, with an smp_wmb() fence between the two
> +stores.  If r1 = 1 and r2 = 0 at the end then there is a prop link
> +from P1's second load to its first (backwards!).  The reason is
> +similar to the previous examples: The value P1 loads from buf gets
> +overwritten by P1's store to buf,

                  P0's store to buf

afzal

> the fence guarantees that the store
> +to buf will propagate to P1 before the store to flag does, and the
> +store to flag propagates to P1 before P1 reads flag.
> +
> +The prop link says that in order to obtain the r1 = 1, r2 = 0 result,
> +P1 must execute its second load before the first.  Indeed, if the load
> +from flag were executed first, then the buf = 1 store would already
> +have propagated to P1 by the time P1's load from buf executed, so r2
> +would have been 1 at the end, not 0.  (The reasoning holds even for
> +Alpha, although the details are more complicated and we will not go
> +into them.)
> +
> +But what if we put an smp_rmb() fence between P1's loads?  The fence
> +would force the two loads to be executed in program order, and it
> +would generate a cycle in the hb relation: The fence would create a ppo
> +link (hence an hb link) from the first load to the second, and the
> +prop relation would give an hb link from the second load to the first.
> +Since an instruction can't execute before itself, we are forced to
> +conclude that if an smp_rmb() fence is added, the r1 = 1, r2 = 0
> +outcome is impossible -- as it should be.

  parent reply	other threads:[~2017-12-19  8:37 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 [this message]
2017-12-19 16:05           ` Alan Stern
2017-12-20 11:31         ` afzal mohammed
2017-12-20 16:45           ` Paul E. McKenney
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=20171219083650.GA10215@afzalpc \
    --to=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=paulmck@linux.vnet.ibm.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