Most implementations of atomic_add_unless() can fail (return 0) after the first
atomic_read() (before cmpxchg). In that case we have a compiler barrier only.
Signed-off-by: Oleg Nesterov <[email protected]>
Documentation/atomic_ops.txt | 3 ++-
Documentation/memory-barriers.txt | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--- 19-rc6/Documentation/memory-barriers.txt~doc 2006-11-27 21:20:20.000000000 +0300
+++ 19-rc6/Documentation/memory-barriers.txt 2006-11-30 03:32:06.000000000 +0300
@@ -1492,7 +1492,7 @@ about the state (old or new) implies an
atomic_dec_and_test();
atomic_sub_and_test();
atomic_add_negative();
- atomic_add_unless();
+ atomic_add_unless(); /* when succeeds (returns 1) */
test_and_set_bit();
test_and_clear_bit();
test_and_change_bit();
--- 19-rc6/Documentation/atomic_ops.txt~doc 2006-07-29 05:05:33.000000000 +0400
+++ 19-rc6/Documentation/atomic_ops.txt 2006-11-30 03:22:58.000000000 +0300
@@ -137,7 +137,8 @@ If the atomic value v is not equal to u,
returns non zero. If v is equal to u then it returns zero. This is done as
an atomic operation.
-atomic_add_unless requires explicit memory barriers around the operation.
+atomic_add_unless requires explicit memory barriers around the operation
+unless it fails (returns 0).
atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
Oleg Nesterov <[email protected]> wrote:
> Most implementations of atomic_add_unless() can fail (return 0) after the
> first atomic_read() (before cmpxchg). In that case we have a compiler
> barrier only.
Ummm... I wonder if we should instead change the behaviour of
atomic_add_unless() to include an explicit smp_rmb() between the read and the
conditional jump on all archs where this isn't already implied. Otherwise,
what governs when the initial test going to be done by the CPU?
Note that not all archs do cmpxchg() here, though I don't think that affects
your argument.
David