1818//!
1919//! Each method takes an [`Ordering`] which represents the strength of
2020//! the memory barrier for that operation. These orderings are the
21- //! same as [LLVM atomic orderings][1]. For more information see the [nomicon][2].
21+ //! same as the [C++20 atomic orderings][1]. For more information see the [nomicon][2].
2222//!
2323//! [`Ordering`]: enum.Ordering.html
2424//!
25- //! [1]: https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations
25+ //! [1]: https://en.cppreference.com/w/cpp/atomic/memory_order
2626//! [2]: ../../../nomicon/atomics.html
2727//!
2828//! Atomic variables are safe to share between threads (they implement [`Sync`])
@@ -217,8 +217,8 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
217217/// operations synchronize other memory while additionally preserving a total order of such
218218/// operations across all threads.
219219///
220- /// Rust's memory orderings are [the same as
221- /// LLVM's ](https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations ).
220+ /// Rust's memory orderings are [the same as those of
221+ /// C++20 ](https://en.cppreference.com/w/cpp/atomic/memory_order ).
222222///
223223/// For more information see the [nomicon].
224224///
@@ -231,9 +231,9 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
231231pub enum Ordering {
232232 /// No ordering constraints, only atomic operations.
233233 ///
234- /// Corresponds to LLVM's [`Monotonic `] ordering .
234+ /// Corresponds to [`memory_order_relaxed `] in C++20 .
235235 ///
236- /// [`Monotonic `]: https://llvm.org/docs/Atomics.html#monotonic
236+ /// [`memory_order_relaxed `]: https://en.cppreference.com/w/cpp/atomic/memory_order#Relaxed_ordering
237237 #[ stable( feature = "rust1" , since = "1.0.0" ) ]
238238 Relaxed ,
239239 /// When coupled with a store, all previous operations become ordered
@@ -246,11 +246,12 @@ pub enum Ordering {
246246 ///
247247 /// This ordering is only applicable for operations that can perform a store.
248248 ///
249- /// Corresponds to LLVM's [`Release `] ordering .
249+ /// Corresponds to [`memory_order_release `] in C++20 .
250250 ///
251- /// [`Release`]: https://llvm.org/docs/Atomics.html#release
252- /// [`Acquire`]: https://llvm.org/docs/Atomics.html#acquire
253- /// [`Relaxed`]: https://llvm.org/docs/Atomics.html#monotonic
251+ /// [`Release`]: #variant.Release
252+ /// [`Acquire`]: #variant.Acquire
253+ /// [`Relaxed`]: #variant.Relaxed
254+ /// [`memory_order_release`]: https://en.cppreference.com/w/cpp/atomic/memory_order#Release-Acquire_ordering
254255 #[ stable( feature = "rust1" , since = "1.0.0" ) ]
255256 Release ,
256257 /// When coupled with a load, if the loaded value was written by a store operation with
@@ -263,40 +264,41 @@ pub enum Ordering {
263264 ///
264265 /// This ordering is only applicable for operations that can perform a load.
265266 ///
266- /// Corresponds to LLVM's [`Acquire `] ordering .
267+ /// Corresponds to [`memory_order_acquire `] in C++20 .
267268 ///
268- /// [`Acquire`]: https://llvm.org/docs/Atomics.html#acquire
269- /// [`Release`]: https://llvm.org/docs/Atomics.html#release
270- /// [`Relaxed`]: https://llvm.org/docs/Atomics.html#monotonic
269+ /// [`Acquire`]: #variant.Acquire
270+ /// [`Release`]: #variant.Release
271+ /// [`Relaxed`]: #variant.Relaxed
272+ /// [`memory_order_acquire`]: https://en.cppreference.com/w/cpp/atomic/memory_order#Release-Acquire_ordering
271273 #[ stable( feature = "rust1" , since = "1.0.0" ) ]
272274 Acquire ,
273275 /// Has the effects of both [`Acquire`] and [`Release`] together:
274276 /// For loads it uses [`Acquire`] ordering. For stores it uses the [`Release`] ordering.
275277 ///
276278 /// Notice that in the case of `compare_and_swap`, it is possible that the operation ends up
277279 /// not performing any store and hence it has just [`Acquire`] ordering. However,
278- /// [ `AcqRel`][`AcquireRelease`] will never perform [`Relaxed`] accesses.
280+ /// `AcqRel` will never perform [`Relaxed`] accesses.
279281 ///
280282 /// This ordering is only applicable for operations that combine both loads and stores.
281283 ///
282- /// Corresponds to LLVM's [`AcquireRelease `] ordering .
284+ /// Corresponds to [`memory_order_acq_rel `] in C++20 .
283285 ///
284- /// [`AcquireRelease `]: https://llvm.org/docs/Atomics.html#acquirerelease
285- /// [`Acquire`]: https://llvm.org/docs/Atomics.html#acquire
286- /// [`Release`]: https://llvm.org/docs/Atomics.html#release
287- /// [`Relaxed`]: https://llvm.org/docs/Atomics.html#monotonic
286+ /// [`memory_order_acq_rel `]: https://en.cppreference.com/w/cpp/atomic/memory_order#Release-Acquire_ordering
287+ /// [`Acquire`]: #variant.Acquire
288+ /// [`Release`]: #variant.Release
289+ /// [`Relaxed`]: #variant.Relaxed
288290 #[ stable( feature = "rust1" , since = "1.0.0" ) ]
289291 AcqRel ,
290292 /// Like [`Acquire`]/[`Release`]/[`AcqRel`] (for load, store, and load-with-store
291293 /// operations, respectively) with the additional guarantee that all threads see all
292294 /// sequentially consistent operations in the same order.
293295 ///
294- /// Corresponds to LLVM's [`SequentiallyConsistent `] ordering .
296+ /// Corresponds to [`memory_order_seq_cst `] in C++20 .
295297 ///
296- /// [`SequentiallyConsistent `]: https://llvm.org/docs/Atomics.html#sequentiallyconsistent
297- /// [`Acquire`]: https://llvm.org/docs/Atomics.html#acquire
298- /// [`Release`]: https://llvm.org/docs/Atomics.html#release
299- /// [`AcqRel`]: https://llvm.org/docs/Atomics.html#acquirerelease
298+ /// [`memory_order_seq_cst `]: https://en.cppreference.com/w/cpp/atomic/memory_order#Sequentially-consistent_ordering
299+ /// [`Acquire`]: #variant.Acquire
300+ /// [`Release`]: #variant.Release
301+ /// [`AcqRel`]: #variant.AcqRel
300302 #[ stable( feature = "rust1" , since = "1.0.0" ) ]
301303 SeqCst ,
302304}
0 commit comments