From ca110694c6950dfd7bc864138c80fe39ea43da5b Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Wed, 23 Aug 2017 18:15:20 +0200 Subject: [PATCH] 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 Signed-off-by: Peter Zijlstra (Intel) Cc: Boqun Feng Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Signed-off-by: Ingo Molnar --- Documentation/atomic_t.txt | 42 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index eee127115277..913396ac5824 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -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.