f68f031d ("Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()")

Hello, Alan,

Just following up on the -rcu commit below. I believe that it needs some adjustment given Peter Zijlstra's addition of "memory" to the x86 non-value-returning atomics, but thought I should double-check.

Quoted 5 lines · Paul E. McKenney

Hello, Alan,

Just following up on the -rcu commit below. I believe that it needs some adjustment given Peter Zijlstra's addition of "memory" to the x86 non-value-returning atomics, but thought I should double-check.

Right; I should get back to that thread...

Quoted 7 lines · Peter Zijlstra

Quoted 5 lines · Paul E. McKenney

Hello, Alan,

Just following up on the -rcu commit below. I believe that it needs some adjustment given Peter Zijlstra's addition of "memory" to the x86 non-value-returning atomics, but thought I should double-check.

Quoted 1 line

Right; I should get back to that thread...

The real question, still outstanding, is whether smp_mb__before_atomic orders anything following the RMW instruction (and similarly, whether smp_mb__after_atomic orders anything preceding the RMW instruction).

Quoted 9 lines · Alan Stern

Quoted 7 lines · Peter Zijlstra

Quoted 5 lines · Paul E. McKenney

Hello, Alan,

Just following up on the -rcu commit below. I believe that it needs some adjustment given Peter Zijlstra's addition of "memory" to the x86 non-value-returning atomics, but thought I should double-check.

Quoted 5 lines

Quoted 1 line

Right; I should get back to that thread...

The real question, still outstanding, is whether smp_mb__before_atomic orders anything following the RMW instruction (and similarly, whether smp_mb__after_atomic orders anything preceding the RMW instruction).

Yes -- that was very much the intent, and only (some) x86 ops and (some) MIPS config have issues with that.

The description of smp_mb__before_atomic() and smp_mb__after_atomic() in Documentation/atomic_t.txt is slightly terse and misleading. It does not clearly state which other instructions are ordered by these barriers.

This improves the text to make the actual ordering implications clear, and also to explain how these barriers differ from a RELEASE or ACQUIRE ordering.

Signed-off-by Alan Stern <[email protected]>

CC Peter Zijlstra <[email protected]>

---

v2: Update the explanation: These barriers do provide order for accesses on the far side of the atomic RMW operation.

 Documentation/atomic_t.txt |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

Index: usb-devel/Documentation/atomic_t.txt
===================================================================

Documentation/atomic_t.txt +13 -4

@@ -170,8 +170,14 @@ The barriers:
 
   smp_mb__{before,after}_atomic()
 
-only apply to the RMW ops and can be used to augment/upgrade the ordering
-inherent to the used atomic op. These barriers provide a full smp_mb().
+only apply to the RMW atomic ops and can be used to augment/upgrade the
+ordering inherent to the op. These barriers act almost like a full smp_mb():
+smp_mb__before_atomic() orders all earlier accesses against the RMW op
+itself and all accesses following it, and smp_mb__after_atomic() orders all
+later accesses against the RMW op and all accesses preceding it. However,
+accesses between the smp_mb__{before,after}_atomic() and the RMW op are not
+ordered, so it is advisable to place the barrier right next to the RMW atomic
+op whenever possible.
 
 These helper barriers exist because architectures have varying implicit
 ordering on their SMP atomic primitives. For example our TSO architectures

@@ -195,7 +201,9 @@ Further, while something like:
   atomic_dec(&X);
 
 is a 'typical' RELEASE pattern, the barrier is strictly stronger than
-a RELEASE. Similarly for something like:
+a RELEASE because it orders preceding instructions against both the read
+and write parts of the atomic_dec(), and against all following instructions
+as well. Similarly, something like:
 
   atomic_inc(&X);
   smp_mb__after_atomic();

@@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus
 
 This should not happen; but a hypothetical atomic_inc_acquire() --
 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
-since then:
+because it would not order the W part of the RMW against the following
+WRITE_ONCE.  Thus:
 
   P1			P2
 

Quoted 9 lines · Alan Stern

The description of smp_mb__before_atomic() and smp_mb__after_atomic() in Documentation/atomic_t.txt is slightly terse and misleading. It does not clearly state which other instructions are ordered by these barriers.

This improves the text to make the actual ordering implications clear, and also to explain how these barriers differ from a RELEASE or ACQUIRE ordering.

Quoted 2 lines

Signed-off-by Alan Stern <[email protected]>

CC Peter Zijlstra <[email protected]>

I understand that this does indeed better describe the intended semantics:

Acked-by Andrea Parri <[email protected]>

Now we would only need to fix the implementations and a few (mis)uses. ;-)

Andrea

Quoted 53 lines

---

v2: Update the explanation: These barriers do provide order for accesses on the far side of the atomic RMW operation.

 Documentation/atomic_t.txt |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

Index: usb-devel/Documentation/atomic_t.txt
===================================================================

Documentation/atomic_t.txt +13 -4

@@ -170,8 +170,14 @@ The barriers:
 
   smp_mb__{before,after}_atomic()
 
-only apply to the RMW ops and can be used to augment/upgrade the ordering
-inherent to the used atomic op. These barriers provide a full smp_mb().
+only apply to the RMW atomic ops and can be used to augment/upgrade the
+ordering inherent to the op. These barriers act almost like a full smp_mb():
+smp_mb__before_atomic() orders all earlier accesses against the RMW op
+itself and all accesses following it, and smp_mb__after_atomic() orders all
+later accesses against the RMW op and all accesses preceding it. However,
+accesses between the smp_mb__{before,after}_atomic() and the RMW op are not
+ordered, so it is advisable to place the barrier right next to the RMW atomic
+op whenever possible.
 
 These helper barriers exist because architectures have varying implicit
 ordering on their SMP atomic primitives. For example our TSO architectures

@@ -195,7 +201,9 @@ Further, while something like:
   atomic_dec(&X);
 
 is a 'typical' RELEASE pattern, the barrier is strictly stronger than
-a RELEASE. Similarly for something like:
+a RELEASE because it orders preceding instructions against both the read
+and write parts of the atomic_dec(), and against all following instructions
+as well. Similarly, something like:
 
   atomic_inc(&X);
   smp_mb__after_atomic();

@@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus
 
 This should not happen; but a hypothetical atomic_inc_acquire() --
 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
-since then:
+because it would not order the W part of the RMW against the following
+WRITE_ONCE.  Thus:
 
   P1			P2