Re: Prototype patch for Linux-kernel memory model

[afzal mohammed]

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.