RISC-V: Comment on why {,cmp}xchg is ordered how it is

This is another memory model FIXME.

Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
This commit is contained in:
Palmer Dabbelt 2017-11-28 14:02:50 -08:00
parent 4650d02ad2
commit 8286d51a6c
1 changed files with 7 additions and 2 deletions

View File

@ -300,8 +300,13 @@ static __always_inline long atomic64_inc_not_zero(atomic64_t *v)
/*
* atomic_{cmp,}xchg is required to have exactly the same ordering semantics as
* {cmp,}xchg and the operations that return, so they need a barrier. We just
* use the other implementations directly.
* {cmp,}xchg and the operations that return, so they need a barrier.
*/
/*
* FIXME: atomic_cmpxchg_{acquire,release,relaxed} are all implemented by
* assigning the same barrier to both the LR and SC operations, but that might
* not make any sense. We're waiting on a memory model specification to
* determine exactly what the right thing to do is here.
*/
#define ATOMIC_OP(c_t, prefix, c_or, size, asm_or) \
static __always_inline c_t atomic##prefix##_cmpxchg##c_or(atomic##prefix##_t *v, c_t o, c_t n) \