doc/uatomic-api.md

   1 <!--
   2 SPDX-FileCopyrightText: 2023 EfficiOS Inc.
   3
   4 SPDX-License-Identifier: CC-BY-4.0
   5 -->
   6
   7 Userspace RCU Atomic Operations API
   8 ===================================
   9
  10 by Mathieu Desnoyers and Paul E. McKenney
  11
  12 This document describes the `<urcu/uatomic.h>` API. Those are the atomic
  13 operations provided by the Userspace RCU library. The general rule
  14 regarding memory barriers is that only `uatomic_xchg()`,
  15 `uatomic_cmpxchg()`, `uatomic_add_return()`, and `uatomic_sub_return()` imply
  16 full memory barriers before and after the atomic operation. Other
  17 primitives don't guarantee any memory barrier.
  18
  19 Only atomic operations performed on integers (`int` and `long`, signed
  20 and unsigned) are supported on all architectures. Some architectures
  21 also support 1-byte and 2-byte atomic operations. Those respectively
  22 have `UATOMIC_HAS_ATOMIC_BYTE` and `UATOMIC_HAS_ATOMIC_SHORT` defined when
  23 `uatomic.h` is included. An architecture trying to perform an atomic write
  24 to a type size not supported by the architecture will trigger an illegal
  25 instruction.
  26
  27 In the description below, `type` is a type that can be atomically
  28 written to by the architecture. It needs to be at most word-sized, and
  29 its alignment needs to greater or equal to its size.
  30
  31
  32 API
  33 ---
  34
  35 ```c
  36 void uatomic_set(type *addr, type v);
  37 ```
  38
  39 Atomically write `v` into `addr`. By "atomically", we mean that no
  40 concurrent operation that reads from addr will see partial
  41 effects of `uatomic_set()`.
  42
  43
  44 ```c
  45 type uatomic_read(type *addr);
  46 ```
  47
  48 Atomically read `v` from `addr`. By "atomically", we mean that
  49 `uatomic_read()` cannot see a partial effect of any concurrent
  50 uatomic update.
  51
  52
  53 ```c
  54 type uatomic_cmpxchg(type *addr, type old, type new);
  55 ```
  56
  57 An atomic read-modify-write operation that performs this
  58 sequence of operations atomically: check if `addr` contains `old`.
  59 If true, then replace the content of `addr` by `new`. Return the
  60 value previously contained by `addr`. This function implies a full
  61 memory barrier before and after the atomic operation on success.
  62 On failure, no memory order is guaranteed.
  63
  64
  65 ```c
  66 type uatomic_xchg(type *addr, type new);
  67 ```
  68
  69 An atomic read-modify-write operation that performs this sequence
  70 of operations atomically: replace the content of `addr` by `new`,
  71 and return the value previously contained by `addr`. This
  72 function implies a full memory barrier before and after the atomic
  73 operation.
  74
  75
  76 ```c
  77 type uatomic_add_return(type *addr, type v);
  78 type uatomic_sub_return(type *addr, type v);
  79 ```
  80
  81 An atomic read-modify-write operation that performs this
  82 sequence of operations atomically: increment/decrement the
  83 content of `addr` by `v`, and return the resulting value. This
  84 function implies a full memory barrier before and after the atomic
  85 operation.
  86
  87
  88 ```c
  89 void uatomic_and(type *addr, type mask);
  90 void uatomic_or(type *addr, type mask);
  91 ```
  92
  93 Atomically write the result of bitwise "and"/"or" between the
  94 content of `addr` and `mask` into `addr`.
  95
  96 These operations do not necessarily imply memory barriers.
  97 If memory barriers are needed, they may be provided by explicitly using
  98 `cmm_smp_mb__before_uatomic_and()`, `cmm_smp_mb__after_uatomic_and()`,
  99 `cmm_smp_mb__before_uatomic_or()`, and `cmm_smp_mb__after_uatomic_or()`.
 100 These explicit barriers are no-ops on architectures in which the underlying
 101 atomic instructions implicitly supply the needed memory barriers.
 102
 103
 104 ```c
 105 void uatomic_add(type *addr, type v);
 106 void uatomic_sub(type *addr, type v);
 107 ```
 108
 109 Atomically increment/decrement the content of `addr` by `v`.
 110 These operations do not necessarily imply memory barriers.
 111 If memory barriers are needed, they may be provided by
 112 explicitly using `cmm_smp_mb__before_uatomic_add()`,
 113 `cmm_smp_mb__after_uatomic_add()`, `cmm_smp_mb__before_uatomic_sub()`, and
 114 `cmm_smp_mb__after_uatomic_sub()`. These explicit barriers are
 115 no-ops on architectures in which the underlying atomic
 116 instructions implicitly supply the needed memory barriers.
 117
 118
 119 ```c
 120 void uatomic_inc(type *addr);
 121 void uatomic_dec(type *addr);
 122 ```
 123
 124 Atomically increment/decrement the content of `addr` by 1.
 125 These operations do not necessarily imply memory barriers.
 126 If memory barriers are needed, they may be provided by
 127 explicitly using `cmm_smp_mb__before_uatomic_inc()`,
 128 `cmm_smp_mb__after_uatomic_inc()`, `cmm_smp_mb__before_uatomic_dec()`,
 129 and `cmm_smp_mb__after_uatomic_dec()`. These explicit barriers are
 130 no-ops on architectures in which the underlying atomic
 131 instructions implicitly supply the needed memory barriers.