On Fri, 20 Dec 2024, Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote: > Hi, [...] > * Introduction of the CMM memory model with the following new primitives: > > - uatomic_load(addr, memory_order) > > - uatomic_store(addr, value, memory_order) > - uatomic_and_mo(addr, mask, memory_order) > - uatomic_or_mo(addr, mask, memory_order) > - uatomic_add_mo(addr, value, memory_order) > - uatomic_sub_mo(addr, value, memory_order) > - uatomic_inc_mo(addr, memory_order) > - uatomic_dec_mo(addr, memory_order) > > - uatomic_add_return_mo(addr, value, memory_order) > - uatomic_sub_return_mo(addr, value, memory_order) > > - uatomic_xchg_mo(addr, value, memory_order) > > - uatomic_cmpxchg_mo(addr, old, new, > memory_order_success, > memory_order_failure) > > The uatomic API was extended to support explicit memory ordering. > For instance, the previous uatomic_cmpxchg() now has a > uatomic_cmpxchg_mo() counterpart, which takes a memory ordering > argument.
It is worth mentioning that the `*_mo' variants are not public API. Instead, the current uatomic API is extended by adding an optional memory odring parameter for the various atomic operation. For example, uatomic_xchg(addr, value) is equivalent to uatomic_xchg(addr, value, CMM_SEQ_CST_FENCE). But user can choose a different memory ordering. For example: uatomix_xchg(addr, value, CMM_RELEASE). [...] Thanks, Olivier -- Olivier Dion EfficiOS Inc. https://www.efficios.com
