Commit ca110694 authored Aug 23, 2017 by Peter Zijlstra Committed by Ingo Molnar Aug 25, 2017

Documentation/locking/atomic: Finish the document...

Julia reported that the document looked unfinished, and it is. I
forgot to include the example cooked up by Paul here:

  https://lkml.kernel.org/r/20170731174345.GL3730@linux.vnet.ibm.com



and I added an explicit example showing how, while it is an ACQUIRE
pattern, it really does provide an MB.

Reported-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

parent e6f3faa7

Documentation/atomic_t.txt

+42 −0

Original line number	Diff line number	Diff line
		@@ -197,4 +197,46 @@ Further, while something like:
		is a 'typical' RELEASE pattern, the barrier is strictly stronger than
		a RELEASE. Similarly for something like:

		atomic_inc(&X);
		smp_mb__after_atomic();

		is an ACQUIRE pattern (though very much not typical), but again the barrier is
		strictly stronger than ACQUIRE. As illustrated:

		C strong-acquire

		{
		}

		P1(int x, atomic_t y)
		{
		r0 = READ_ONCE(*x);
		smp_rmb();
		r1 = atomic_read(y);
		}

		P2(int x, atomic_t y)
		{
		atomic_inc(y);
		smp_mb__after_atomic();
		WRITE_ONCE(*x, 1);
		}

		exists
		(r0=1 /\ r1=0)

		This should not happen; but a hypothetical atomic_inc_acquire() --
		(void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
		since then:

		P1 P2

		t = LL.acq *y (0)
		t++;
		*x = 1;
		r0 = *x (1)
		RMB
		r1 = *y (0)
		SC *y, t;

		is allowed.