mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-08-26 10:49:33 +00:00
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:
parent
4650d02ad2
commit
8286d51a6c
1 changed files with 7 additions and 2 deletions
|
@ -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
|
* 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
|
* {cmp,}xchg and the operations that return, so they need a barrier.
|
||||||
* use the other implementations directly.
|
*/
|
||||||
|
/*
|
||||||
|
* 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) \
|
#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) \
|
static __always_inline c_t atomic##prefix##_cmpxchg##c_or(atomic##prefix##_t *v, c_t o, c_t n) \
|
||||||
|
|
Loading…
Reference in a new issue