On Mon, Jul 27, 2015 at 11:21:06AM +0100, Will Deacon wrote: > On Mon, Jul 27, 2015 at 10:14:30AM +0100, Peter Zijlstra wrote: > > On Fri, Jul 24, 2015 at 03:04:34PM +0100, Will Deacon wrote: > > > This patch introduces three new ordering semantics for these operations: > > > > > > - *_relaxed: No ordering guarantees. This is similar to what we have > > > already for the non-return atomics (e.g. atomic_add). > > > > > > - *_acquire: ACQUIRE semantics, similar to smp_load_acquire. > > > > > > - *_release: RELEASE semantics, similar to smp_store_release. > > > > Do we want to further specify that for the RmW operations the Read/load > > will provide the acquire and the Write/store the release? > > Yeah, that's not a bad idea, but if we add that then I probably need to > re-iterate the cmpxchg strangeness since a failed cmpxchg_acquire would > still not have barrier semantics with the current implementation even though > it must have performed a Read/load access.
Something like below? Will --->8 diff --git a/include/linux/atomic.h b/include/linux/atomic.h index 899b4035569e..d2515c05e7c8 100644 --- a/include/linux/atomic.h +++ b/include/linux/atomic.h @@ -14,6 +14,11 @@ * - Release: Provides RELEASE semantics, _release suffix. * - Relaxed: No ordering guarantees, _relaxed suffix. * + * For compound atomics performing both a load and a store, ACQUIRE + * semantics apply only to the load and RELEASE semantics only to the + * store portion of the operation. Note that a failed cmpxchg_acquire + * does -not- imply any memory ordering constraints. + * * See Documentation/memory-barriers.txt for ACQUIRE/RELEASE definitions. */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
