All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tip-bot2 for Peter Zijlstra" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Will Deacon <will@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: locking/core] Documentation/atomic_t: Document cmpxchg() vs try_cmpxchg()
Date: Thu, 08 Jul 2021 08:42:33 -0000	[thread overview]
Message-ID: <162573375370.395.17829380230599129573.tip-bot2@tip-bot2> (raw)
In-Reply-To: <YOMgPeMOmmiK3tXO@hirez.programming.kicks-ass.net>

The following commit has been merged into the locking/core branch of tip:

Commit-ID:     d1bbfd0c7c9f985e57795a7e0cefc209ebf689c0
Gitweb:        https://git.kernel.org/tip/d1bbfd0c7c9f985e57795a7e0cefc209ebf689c0
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Mon, 05 Jul 2021 17:00:24 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Wed, 07 Jul 2021 13:53:25 +02:00

Documentation/atomic_t: Document cmpxchg() vs try_cmpxchg()

There seems to be a significant amount of confusion around the new
try_cmpxchg(), despite this being more like the C11
atomic_compare_exchange_*() family. Add a few words of clarification
on how cmpxchg() and try_cmpxchg() relate to one another.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/r/YOMgPeMOmmiK3tXO@hirez.programming.kicks-ass.net
---
 Documentation/atomic_t.txt | 41 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+)

diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
index 0f1fded..a9c1e2b 100644
--- a/Documentation/atomic_t.txt
+++ b/Documentation/atomic_t.txt
@@ -271,3 +271,44 @@ WRITE_ONCE.  Thus:
 			SC *y, t;
 
 is allowed.
+
+
+CMPXCHG vs TRY_CMPXCHG
+----------------------
+
+  int atomic_cmpxchg(atomic_t *ptr, int old, int new);
+  bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new);
+
+Both provide the same functionality, but try_cmpxchg() can lead to more
+compact code. The functions relate like:
+
+  bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new)
+  {
+    int ret, old = *oldp;
+    ret = atomic_cmpxchg(ptr, old, new);
+    if (ret != old)
+      *oldp = ret;
+    return ret == old;
+  }
+
+and:
+
+  int atomic_cmpxchg(atomic_t *ptr, int old, int new)
+  {
+    (void)atomic_try_cmpxchg(ptr, &old, new);
+    return old;
+  }
+
+Usage:
+
+  old = atomic_read(&v);			old = atomic_read(&v);
+  for (;;) {					do {
+    new = func(old);				  new = func(old);
+    tmp = atomic_cmpxchg(&v, old, new);		} while (!atomic_try_cmpxchg(&v, &old, new));
+    if (tmp == old)
+      break;
+    old = tmp;
+  }
+
+NB. try_cmpxchg() also generates better code on some platforms (notably x86)
+where the function more closely matches the hardware instruction.

  parent reply	other threads:[~2021-07-08  8:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30 15:35 [RFC][PATCH 0/4] locking/mutex: Some HANDOFF fixes Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 1/4] locking/mutex: Use try_cmpxchg() Peter Zijlstra
2021-07-05 11:59   ` Xu, Yanfei
2021-07-05 14:00     ` Peter Zijlstra
2021-07-05 14:52       ` Xu, Yanfei
2021-07-05 15:07       ` [PATCH] Documentation/atomic_t: Document cmpxchg() vs try_cmpxchg() Peter Zijlstra
2021-07-05 15:21         ` Will Deacon
2021-07-05 15:25         ` Xu, Yanfei
2021-07-05 17:12           ` Peter Zijlstra
2021-07-08  8:42         ` tip-bot2 for Peter Zijlstra [this message]
2021-07-08  8:42   ` [tip: locking/core] locking/mutex: Use try_cmpxchg() tip-bot2 for Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 2/4] locking/mutex: Fix HANDOFF condition Peter Zijlstra
2021-07-08  8:42   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 3/4] locking/mutex: Introduce __mutex_trylock_or_handoff() Peter Zijlstra
2021-06-30 16:30   ` Waiman Long
2021-06-30 18:04     ` Peter Zijlstra
2021-07-08  8:42   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-06-30 15:35 ` [RFC][PATCH 4/4] locking/mutex: Add MUTEX_WARN_ON Peter Zijlstra
2021-07-08  8:42   ` [tip: locking/core] " tip-bot2 for Peter Zijlstra
2021-06-30 19:03 ` [RFC][PATCH 0/4] locking/mutex: Some HANDOFF fixes Waiman Long
2021-07-01  2:11 ` Xu, Yanfei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=162573375370.395.17829380230599129573.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.