Re: [RFC 2/5] atomics: introduce arch_atomic_op_{acquire,release,fence} helpers
From: Peter Zijlstra <peterz@infradead.org>
Date: 2015-08-28 11:36:23
Also in:
lkml
On Fri, Aug 28, 2015 at 10:48:16AM +0800, Boqun Feng wrote:
quoted hunk ↗ jump to hunk
Some architectures may have their special barriers for acquire, release and fence semantics, general memory barriers(smp_mb__*_atomic()) in __atomic_op_*() may be too strong, so arch_atomic_op_*() helpers are introduced for architectures to provide their own version helpers to build different variants based on _relaxed variants. Signed-off-by: Boqun Feng <redacted> --- include/linux/atomic.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)diff --git a/include/linux/atomic.h b/include/linux/atomic.h index 00a5763..622255b 100644 --- a/include/linux/atomic.h +++ b/include/linux/atomic.h@@ -34,20 +34,33 @@ * The idea here is to build acquire/release variants by adding explicit * barriers on top of the relaxed variant. In the case where the relaxed * variant is already fully ordered, no additional barriers are needed. + * + * Besides, if an arch has a special barrier for acquire/release, it could + * implement its own arch_atomic_op_* and use the same framework for building + * variants */ +#ifndef arch_atomic_op_acquire #define __atomic_op_acquire(op, args...) \ ({ \ typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \ smp_mb__after_atomic(); \ __ret; \ }) +#else +#define __atomic_op_acquire arch_atomic_op_acquire +#endif
Not really a fan of this, its not consistent with the existing #ifndef guard style.