mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-29 02:03:53 +00:00
Rollup merge of #56023 - vorner:doc/atomic-ordering-strip, r=@stjepang
atomic::Ordering: Get rid of misleading parts of intro Remove the parts of atomic::Ordering's intro that wrongly claimed that SeqCst prevents all reorderings around it. Closes #55196 This is a (minimal) alternative to #55233. I also wonder if it would be worth adding at least some warnings that atomics are often a footgun/hard to use correctly, similarly like `mem::transmute` or other functions have.
This commit is contained in:
commit
5d395add7f
@ -173,11 +173,11 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
|
||||
|
||||
/// Atomic memory orderings
|
||||
///
|
||||
/// Memory orderings limit the ways that both the compiler and CPU may reorder
|
||||
/// instructions around atomic operations. At its most restrictive,
|
||||
/// "sequentially consistent" atomics allow neither reads nor writes
|
||||
/// to be moved either before or after the atomic operation; on the other end
|
||||
/// "relaxed" atomics allow all reorderings.
|
||||
/// Memory orderings specify the way atomic operations synchronize memory.
|
||||
/// In its weakest [`Relaxed`][Ordering::Relaxed], only the memory directly touched by the
|
||||
/// operation is synchronized. On the other hand, a store-load pair of [`SeqCst`][Ordering::SeqCst]
|
||||
/// operations synchronize other memory while additionally preserving a total order of such
|
||||
/// operations across all threads.
|
||||
///
|
||||
/// Rust's memory orderings are [the same as
|
||||
/// LLVM's](https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations).
|
||||
@ -185,6 +185,8 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
|
||||
/// For more information see the [nomicon].
|
||||
///
|
||||
/// [nomicon]: ../../../nomicon/atomics.html
|
||||
/// [Ordering::Relaxed]: #variant.Relaxed
|
||||
/// [Ordering::SeqCst]: #variant.SeqCst
|
||||
#[stable(feature = "rust1", since = "1.0.0")]
|
||||
#[derive(Copy, Clone, Debug)]
|
||||
#[non_exhaustive]
|
||||
@ -234,8 +236,8 @@ pub enum Ordering {
|
||||
/// For loads it uses [`Acquire`] ordering. For stores it uses the [`Release`] ordering.
|
||||
///
|
||||
/// Notice that in the case of `compare_and_swap`, it is possible that the operation ends up
|
||||
/// not performing any store and hence it has just `Acquire` ordering. However,
|
||||
/// `AcqRel` will never perform [`Relaxed`] accesses.
|
||||
/// not performing any store and hence it has just [`Acquire`] ordering. However,
|
||||
/// [`AcqRel`][`AcquireRelease`] will never perform [`Relaxed`] accesses.
|
||||
///
|
||||
/// This ordering is only applicable for operations that combine both loads and stores.
|
||||
///
|
||||
|
Loading…
Reference in New Issue
Block a user