Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1410103 > unrolled thread

[PATCH -v2 32/33] locking,qrwlock: Employ atomic_fetch_add_acquire()

Started byPeter Zijlstra <peterz@infradead.org>
First post2016-05-31 12:40 +0200
Last post2016-05-31 12:40 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH -v2 32/33] locking,qrwlock: Employ atomic_fetch_add_acquire() Peter Zijlstra <peterz@infradead.org> - 2016-05-31 12:40 +0200

#1410103 — [PATCH -v2 32/33] locking,qrwlock: Employ atomic_fetch_add_acquire()

FromPeter Zijlstra <peterz@infradead.org>
Date2016-05-31 12:40 +0200
Subject[PATCH -v2 32/33] locking,qrwlock: Employ atomic_fetch_add_acquire()
Message-ID<rEPfA-1vx-51@gated-at.bofh.it>
The only reason for the current code is to make GCC emit only the
"LOCK XADD" instruction on x86 (and not do a pointless extra ADD on
the result), do so nicer.

Acked-by: Waiman Long <waiman.long@hpe.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/locking/qrwlock.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -93,7 +93,7 @@ void queued_read_lock_slowpath(struct qr
 	 * that accesses can't leak upwards out of our subsequent critical
 	 * section in the case that the lock is currently held for write.
 	 */
-	cnts = atomic_add_return_acquire(_QR_BIAS, &lock->cnts) - _QR_BIAS;
+	cnts = atomic_fetch_add_acquire(_QR_BIAS, &lock->cnts);
 	rspin_until_writer_unlock(lock, cnts);
 
 	/*

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web