Enum Ordering
enum Ordering
Atomic memory orderings
Memory orderings specify the way atomic operations synchronize memory.
In its weakest Ordering::Relaxed, only the memory directly touched by the
operation is synchronized. On the other hand, a store-load pair of 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 those of C++20.
For more information see the nomicon.
Variants
-
Relaxed No ordering constraints, only atomic operations.
Corresponds to
memory_order_relaxedin C++20.-
Release When coupled with a store, all previous operations become ordered before any load of this value with
Acquire(or stronger) ordering. In particular, all previous writes become visible to all threads that perform anAcquire(or stronger) load of this value.Notice that using this ordering for an operation that combines loads and stores leads to a
Relaxedload operation!This ordering is only applicable for operations that can perform a store.
Corresponds to
memory_order_releasein C++20.-
Acquire When coupled with a load, if the loaded value was written by a store operation with
Release(or stronger) ordering, then all subsequent operations become ordered after that store. In particular, all subsequent loads will see data written before the store.Notice that using this ordering for an operation that combines loads and stores leads to a
Relaxedstore operation!This ordering is only applicable for operations that can perform a load.
Corresponds to
memory_order_acquirein C++20.-
AcqRel Has the effects of both
AcquireandReleasetogether: For loads it usesAcquireordering. For stores it uses theReleaseordering.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 justAcquireordering. However,AcqRelwill never performRelaxedaccesses.This ordering is only applicable for operations that combine both loads and stores.
Corresponds to
memory_order_acq_relin C++20.-
SeqCst Like
Acquire/Release/AcqRel(for load, store, and load-with-store operations, respectively) with the additional guarantee that all threads see all sequentially consistent operations in the same order.Corresponds to
memory_order_seq_cstin C++20.
Implementations
impl Clone for Ordering
fn clone(self: &Self) -> Ordering
impl Copy for Ordering
impl Debug for Ordering
fn fmt(self: &Self, f: &mut $crate::fmt::Formatter<'_>) -> $crate::fmt::Result
impl Eq for Ordering
impl Freeze for Ordering
impl Hash for Ordering
fn hash<__H: $crate::hash::Hasher>(self: &Self, state: &mut __H)
impl PartialEq for Ordering
fn eq(self: &Self, other: &Ordering) -> bool
impl RefUnwindSafe for Ordering
impl Send for Ordering
impl StructuralPartialEq for Ordering
impl Sync for Ordering
impl Unpin for Ordering
impl UnwindSafe for Ordering
impl<T> Any for Ordering
fn type_id(self: &Self) -> TypeId
impl<T> Borrow for Ordering
fn borrow(self: &Self) -> &T
impl<T> BorrowMut for Ordering
fn borrow_mut(self: &mut Self) -> &mut T
impl<T> CloneToUninit for Ordering
unsafe fn clone_to_uninit(self: &Self, dest: *mut u8)
impl<T> From for Ordering
fn from(t: T) -> TReturns the argument unchanged.
impl<T, U> Into for Ordering
fn into(self: Self) -> UCalls
U::from(self).That is, this conversion is whatever the implementation of
[From]<T> for Uchooses to do.
impl<T, U> TryFrom for Ordering
fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>
impl<T, U> TryInto for Ordering
fn try_into(self: Self) -> Result<U, <U as TryFrom<T>>::Error>