tile: clarify barrier semantics of atomic_add_return

A recent discussion on LKML made it clear that the one-line
comment previously in atomic_add_return() was not clear enough:

https://lkml.kernel.org/r/571E87E2.3010306@mellanox.com

Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
This commit is contained in:
Chris Metcalf 2016-04-26 09:54:56 -04:00
parent 85f5251792
commit 153847586b

View File

@ -37,12 +37,25 @@ static inline void atomic_add(int i, atomic_t *v)
__insn_fetchadd4((void *)&v->counter, i);
}
/*
* Note a subtlety of the locking here. We are required to provide a
* full memory barrier before and after the operation. However, we
* only provide an explicit mb before the operation. After the
* operation, we use barrier() to get a full mb for free, because:
*
* (1) The barrier directive to the compiler prohibits any instructions
* being statically hoisted before the barrier;
* (2) the microarchitecture will not issue any further instructions
* until the fetchadd result is available for the "+ i" add instruction;
* (3) the smb_mb before the fetchadd ensures that no other memory
* operations are in flight at this point.
*/
static inline int atomic_add_return(int i, atomic_t *v)
{
int val;
smp_mb(); /* barrier for proper semantics */
val = __insn_fetchadd4((void *)&v->counter, i) + i;
barrier(); /* the "+ i" above will wait on memory */
barrier(); /* equivalent to smp_mb(); see block comment above */
return val;
}
@ -95,7 +108,7 @@ static inline long atomic64_add_return(long i, atomic64_t *v)
int val;
smp_mb(); /* barrier for proper semantics */
val = __insn_fetchadd((void *)&v->counter, i) + i;
barrier(); /* the "+ i" above will wait on memory */
barrier(); /* equivalent to smp_mb; see atomic_add_return() */
return val;
}