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