Date: Wed, 20 Dec 2017 17:01:45 +0530
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
Message-ID: <20171220113145.GA5082@afzalpc>
References: <20171114075925.apzztfksn4f4y5ue@hirez.programming.kicks-ass.net>
 <Pine.LNX.4.44L0.1711141016340.1796-100000@iolanthe.rowland.org>
 <20171114171505.GS3624@linux.vnet.ibm.com>
 <20171115163749.GA8555@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171115163749.GA8555@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1508
Lines: 53

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.

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 ;)

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.