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.
