aboutsummaryrefslogtreecommitdiff
path: root/docs/atomics.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/atomics.txt')
-rw-r--r--docs/atomics.txt16
1 files changed, 13 insertions, 3 deletions
diff --git a/docs/atomics.txt b/docs/atomics.txt
index bba771e..67a27ad 100644
--- a/docs/atomics.txt
+++ b/docs/atomics.txt
@@ -326,9 +326,19 @@ and memory barriers, and the equivalents in QEMU:
use a boxed atomic_t type; atomic operations in QEMU are polymorphic
and use normal C types.
-- atomic_read and atomic_set in Linux give no guarantee at all;
- atomic_read and atomic_set in QEMU include a compiler barrier
- (similar to the READ_ONCE/WRITE_ONCE macros in Linux).
+- Originally, atomic_read and atomic_set in Linux gave no guarantee
+ at all. Linux 4.1 updated them to implement volatile
+ semantics via ACCESS_ONCE (or the more recent READ/WRITE_ONCE).
+
+ QEMU's atomic_read/set implement, if the compiler supports it, C11
+ atomic relaxed semantics, and volatile semantics otherwise.
+ Both semantics prevent the compiler from doing certain transformations;
+ the difference is that atomic accesses are guaranteed to be atomic,
+ while volatile accesses aren't. Thus, in the volatile case we just cross
+ our fingers hoping that the compiler will generate atomic accesses,
+ since we assume the variables passed are machine-word sized and
+ properly aligned.
+ No barriers are implied by atomic_read/set in either Linux or QEMU.
- most atomic read-modify-write operations in Linux return void;
in QEMU, all of them return the old value of the variable.