18
18
//!
19
19
//! Each method takes an [`Ordering`] which represents the strength of
20
20
//! 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].
22
22
//!
23
23
//! [`Ordering`]: enum.Ordering.html
24
24
//!
25
- //! [1]: https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations
25
+ //! [1]: https://en.cppreference.com/w/cpp/atomic/memory_order
26
26
//! [2]: ../../../nomicon/atomics.html
27
27
//!
28
28
//! Atomic variables are safe to share between threads (they implement [`Sync`])
@@ -217,8 +217,8 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
217
217
/// operations synchronize other memory while additionally preserving a total order of such
218
218
/// operations across all threads.
219
219
///
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 ).
222
222
///
223
223
/// For more information see the [nomicon].
224
224
///
@@ -231,9 +231,9 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
231
231
pub enum Ordering {
232
232
/// No ordering constraints, only atomic operations.
233
233
///
234
- /// Corresponds to LLVM's [`Monotonic `] ordering .
234
+ /// Corresponds to [`memory_order_relaxed `] in C++20 .
235
235
///
236
- /// [`Monotonic `]: https://llvm.org/docs/Atomics.html#monotonic
236
+ /// [`memory_order_relaxed `]: https://en.cppreference.com/w/cpp/atomic/memory_order#Relaxed_ordering
237
237
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
238
238
Relaxed ,
239
239
/// When coupled with a store, all previous operations become ordered
@@ -246,11 +246,12 @@ pub enum Ordering {
246
246
///
247
247
/// This ordering is only applicable for operations that can perform a store.
248
248
///
249
- /// Corresponds to LLVM's [`Release `] ordering .
249
+ /// Corresponds to [`memory_order_release `] in C++20 .
250
250
///
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
254
255
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
255
256
Release ,
256
257
/// When coupled with a load, if the loaded value was written by a store operation with
@@ -263,40 +264,41 @@ pub enum Ordering {
263
264
///
264
265
/// This ordering is only applicable for operations that can perform a load.
265
266
///
266
- /// Corresponds to LLVM's [`Acquire `] ordering .
267
+ /// Corresponds to [`memory_order_acquire `] in C++20 .
267
268
///
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
271
273
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
272
274
Acquire ,
273
275
/// Has the effects of both [`Acquire`] and [`Release`] together:
274
276
/// For loads it uses [`Acquire`] ordering. For stores it uses the [`Release`] ordering.
275
277
///
276
278
/// Notice that in the case of `compare_and_swap`, it is possible that the operation ends up
277
279
/// 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.
279
281
///
280
282
/// This ordering is only applicable for operations that combine both loads and stores.
281
283
///
282
- /// Corresponds to LLVM's [`AcquireRelease `] ordering .
284
+ /// Corresponds to [`memory_order_acq_rel `] in C++20 .
283
285
///
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
288
290
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
289
291
AcqRel ,
290
292
/// Like [`Acquire`]/[`Release`]/[`AcqRel`] (for load, store, and load-with-store
291
293
/// operations, respectively) with the additional guarantee that all threads see all
292
294
/// sequentially consistent operations in the same order.
293
295
///
294
- /// Corresponds to LLVM's [`SequentiallyConsistent `] ordering .
296
+ /// Corresponds to [`memory_order_seq_cst `] in C++20 .
295
297
///
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
300
302
#[ stable( feature = "rust1" , since = "1.0.0" ) ]
301
303
SeqCst ,
302
304
}
0 commit comments