diff --git a/share/man/man9/atomic.9 b/share/man/man9/atomic.9
--- a/share/man/man9/atomic.9
+++ b/share/man/man9/atomic.9
@@ -235,6 +235,29 @@
 However, they will not prevent the compiler or processor from moving loads
 or stores into the critical section, which does not violate the semantics of
 a mutex.
+.Ss Architecture-dependent caveats for compare-and-swap
+The
+.Fn atomic_[f]cmpset_<type>
+operations, specifically the ones without explicitly specified memory
+ordering variants, are defined as relaxed.  Arbitrary reordering of
+the memory accesses to a location different from the operation location
+against it, are not prohibited.
+.Pp
+However, the implementation on the
+.Sy x86
+architectures provides sequentially consistent semantics.
+In particular, the reordering mentioned above cannot occur.
+.Pp
+On the
+.Sy arm64/aarch64
+architecture, the operation provides acquire
+semantics for load and release semantics for store accesses.
+This means that accesses to other locations in program order
+before the atomic, might be observed as executed after the load
+that is the part of the atomic operation (but not after the store
+from the operation due to release).
+Similarly, accesses after the atomic might be observed as executed
+before the store.
 .Ss Thread Fence Operations
 Alternatively, a programmer can use atomic thread fence operations to
 constrain the reordering of accesses.