mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

atomic::Ordering: Get rid of misleading parts of intro

Browse Source 
Remove the parts of atomic::Ordering's intro that wrongly claimed that
SeqCst prevents all reorderings around it.

Closes #55196
This commit is contained in:
Michal 'vorner' Vaner 2018-11-17 14:48:18 +01:00
parent f6e9485bfc
commit cc63bd47ef
No known key found for this signature in database
GPG Key ID: F700D0C019E4C66F
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/libcore/sync/atomic.rs
View File

@ -173,11 +173,11 @@ unsafe impl<T> Sync for AtomicPtr<T> {}
/// Atomic memory orderings /// Atomic memory orderings
/// ///
/// Memory orderings limit the ways that both the compiler and CPU may reorder /// Memory orderings specify the way atomic operations synchronize memory.
/// instructions around atomic operations. At its most restrictive, /// In its weakest [`Relaxed`][Ordering::Relaxed], only the memory directly touched by the
/// "sequentially consistent" atomics allow neither reads nor writes /// operation is synchronized. On the other hand, a store-load pair of [`SeqCst`][Ordering::SeqCst]
/// to be moved either before or after the atomic operation; on the other end /// operations synchronize other memory while additionally preserving a total order of such
/// "relaxed" atomics allow all reorderings. /// operations across all threads.
/// ///
/// Rust's memory orderings are [the same as /// Rust's memory orderings are [the same as
/// LLVM's](https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations). /// 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]. /// For more information see the [nomicon].
/// ///
/// [nomicon]: ../../../nomicon/atomics.html /// [nomicon]: ../../../nomicon/atomics.html
/// [Ordering::Relaxed]: #variant.Relaxed
/// [Ordering::SeqCst]: #variant.SeqCst
#[stable(feature = "rust1", since = "1.0.0")] #[stable(feature = "rust1", since = "1.0.0")]
#[derive(Copy, Clone, Debug)] #[derive(Copy, Clone, Debug)]
#[non_exhaustive] #[non_exhaustive]
@ -234,8 +236,8 @@ pub enum Ordering {
/// For loads it uses [`Acquire`] ordering. For stores it uses the [`Release`] 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 /// 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, /// not performing any store and hence it has just [`Acquire`] ordering. However,
/// `AcqRel` will never perform [`Relaxed`] accesses. /// [`AcqRel`][`AcquireRelease`] will never perform [`Relaxed`] accesses.
/// ///
/// This ordering is only applicable for operations that combine both loads and stores. /// This ordering is only applicable for operations that combine both loads and stores.
/// ///