Struct AtomicMaybeUninit 

pub struct AtomicMaybeUninit<T: Primitive> { /* private fields */ }

A potentially uninitialized integer type which can be safely shared between threads.

This type has the same in-memory representation as the underlying value type, MaybeUninit<T>. However, the alignment of this type is always equal to its size, even on targets where MaybeUninit<T> has a lesser alignment.

Implementations

impl<T: Primitive> AtomicMaybeUninit<T>

pub const fn new(v: MaybeUninit<T>) -> Self

Creates a new atomic value from a potentially uninitialized value.

Examples

use std::mem::MaybeUninit;

use atomic_maybe_uninit::AtomicMaybeUninit;

let v = AtomicMaybeUninit::new(MaybeUninit::new(5_i32));

// Equivalent to:
let v = AtomicMaybeUninit::from(5_i32);

pub const unsafe fn from_ptr<'a>(ptr: *mut MaybeUninit<T>) -> &'a Self

Creates a new reference to an atomic value from a pointer.

Safety

• ptr must be aligned to align_of::<AtomicMaybeUninit<T>>() (note that on some platforms this can be bigger than align_of::<MaybeUninit<T>>()).
• ptr must be valid for both reads and writes for the whole lifetime 'a.
• You must adhere to the Memory model for atomic accesses. In particular, it is not allowed to mix conflicting atomic and non-atomic accesses, or atomic accesses of different sizes, without synchronization.

pub const fn get_mut(&mut self) -> &mut MaybeUninit<T>

Returns a mutable reference to the underlying value.

This is safe because the mutable reference guarantees that no other threads are concurrently accessing the atomic data.

This is const fn on Rust 1.83+.

Examples

use std::mem::MaybeUninit;

use atomic_maybe_uninit::AtomicMaybeUninit;

let mut v = AtomicMaybeUninit::from(5_i32);
unsafe { assert_eq!((*v.get_mut()).assume_init(), 5) }
*v.get_mut() = MaybeUninit::new(10);
unsafe { assert_eq!((*v.get_mut()).assume_init(), 10) }

pub const fn into_inner(self) -> MaybeUninit<T>

Consumes the atomic and returns the contained value.

This is safe because passing self by value guarantees that no other threads are concurrently accessing the atomic data.

Examples

use atomic_maybe_uninit::AtomicMaybeUninit;

let v = AtomicMaybeUninit::from(5_i32);
unsafe { assert_eq!(v.into_inner().assume_init(), 5) }

pub fn load(&self, order: Ordering) -> MaybeUninit<T>

where T: AtomicLoad,

Loads a value from the atomic value.

load takes an Ordering argument which describes the memory ordering of this operation. Possible values are SeqCst, Acquire and Relaxed.

Panics

Panics if order is Release or AcqRel.

Examples

use std::sync::atomic::Ordering;

use atomic_maybe_uninit::AtomicMaybeUninit;

let v = AtomicMaybeUninit::from(5_i32);
unsafe { assert_eq!(v.load(Ordering::Relaxed).assume_init(), 5) }

pub fn store(&self, val: MaybeUninit<T>, order: Ordering)

where T: AtomicStore,

Stores a value into the atomic value.

store takes an Ordering argument which describes the memory ordering of this operation. Possible values are SeqCst, Release and Relaxed.

Panics

Panics if order is Acquire or AcqRel.

Examples

use std::{mem::MaybeUninit, sync::atomic::Ordering};

use atomic_maybe_uninit::AtomicMaybeUninit;

let v = AtomicMaybeUninit::from(5_i32);
v.store(MaybeUninit::new(10), Ordering::Relaxed);
unsafe { assert_eq!(v.load(Ordering::Relaxed).assume_init(), 10) }

pub fn swap(&self, val: MaybeUninit<T>, order: Ordering) -> MaybeUninit<T>

where T: AtomicSwap,

Stores a value into the atomic value, returning the previous value.

swap takes an Ordering argument which describes the memory ordering of this operation. All ordering modes are possible. Note that using Acquire makes the store part of this operation Relaxed, and using Release makes the load part Relaxed.

Examples

use std::{mem::MaybeUninit, sync::atomic::Ordering};

use atomic_maybe_uninit::AtomicMaybeUninit;

let v = AtomicMaybeUninit::from(5_i32);
unsafe {
    assert_eq!(v.swap(MaybeUninit::new(10), Ordering::Relaxed).assume_init(), 5);
    assert_eq!(v.load(Ordering::Relaxed).assume_init(), 10);
}

pub fn compare_exchange( &self, current: MaybeUninit<T>, new: MaybeUninit<T>, success: Ordering, failure: Ordering, ) -> Result<MaybeUninit<T>, MaybeUninit<T>>

where T: AtomicCompareExchange,

Stores a value into the atomic value if the current value is the same as the current value. Here, “the same” is determined using byte-wise equality, not PartialEq.

The return value is a result indicating whether the new value was written and containing the previous value. On success this value is guaranteed to be equal to current.

compare_exchange takes two Ordering arguments to describe the memory ordering of this operation. success describes the required ordering for the read-modify-write operation that takes place if the comparison with current succeeds. failure describes the required ordering for the load operation that takes place when the comparison fails. Using Acquire as success ordering makes the store part of this operation Relaxed, and using Release makes the successful load Relaxed. The failure ordering can only be SeqCst, Acquire or Relaxed.

Panics

Panics if failure is Release, AcqRel.

Notes

Comparison of two values containing uninitialized bytes may fail even if they are equivalent as Rust’s type, because values can be byte-wise inequal even when they are equal as Rust values.

For example, the following example could be an infinite loop:

use std::{
    mem::{self, MaybeUninit},
    sync::atomic::Ordering,
};

use atomic_maybe_uninit::AtomicMaybeUninit;

#[derive(Clone, Copy, PartialEq, Eq)]
#[repr(C, align(4))]
struct Test(u8, u16);

unsafe {
    let x = mem::transmute::<Test, MaybeUninit<u32>>(Test(0, 0));
    let v = AtomicMaybeUninit::new(x);
    while v
        .compare_exchange(
            mem::transmute::<Test, MaybeUninit<u32>>(Test(0, 0)),
            mem::transmute::<Test, MaybeUninit<u32>>(Test(1, 0)),
            Ordering::AcqRel,
            Ordering::Acquire,
        )
        .is_err()
    {}
}

To work around this problem, you need to use a helper like the following.

// Adapted from https://github.com/crossbeam-rs/crossbeam/blob/crossbeam-utils-0.8.10/crossbeam-utils/src/atomic/atomic_cell.rs#L1081-L1110
unsafe fn atomic_compare_exchange(
    v: &AtomicMaybeUninit<u32>,
    mut current: Test,
    new: Test,
) -> Result<Test, Test> {
    let mut current_raw = unsafe { mem::transmute::<Test, MaybeUninit<u32>>(current) };
    let new_raw = unsafe { mem::transmute::<Test, MaybeUninit<u32>>(new) };
    loop {
        match v.compare_exchange_weak(current_raw, new_raw, Ordering::AcqRel, Ordering::Acquire)
        {
            Ok(_) => {
                // The values are byte-wise equal; for `Test` we know this implies they are `PartialEq`-equal.
                break Ok(current);
            }
            Err(previous_raw) => {
                let previous = unsafe { mem::transmute::<MaybeUninit<u32>, Test>(previous_raw) };

                if !Test::eq(&previous, &current) {
                    break Err(previous);
                }

                // The compare-exchange operation has failed and didn't store `new`. The
                // failure is either spurious, or `previous` was semantically equal to
                // `current` but not byte-equal. Let's retry with `previous` as the new
                // `current`.
                current = previous;
                current_raw = previous_raw;
            }
        }
    }
}

unsafe {
    let x = mem::transmute::<Test, MaybeUninit<u32>>(Test(0, 0));
    let v = AtomicMaybeUninit::new(x);
    while atomic_compare_exchange(&v, Test(0, 0), Test(1, 0)).is_err() {}
}

Also, Valgrind reports “Conditional jump or move depends on uninitialized value(s)” error if there is such a comparison – which is correct, that’s exactly what the implementation does, but we are doing this inside inline assembly so it should be fine. (Effectively we are adding partial freeze capabilities to Rust via inline assembly. This pattern has not been blessed by the language team, but is also not known to cause any problems.)

Examples

use std::{mem::MaybeUninit, sync::atomic::Ordering};

use atomic_maybe_uninit::AtomicMaybeUninit;

unsafe {
    let v = AtomicMaybeUninit::from(5_i32);

    assert_eq!(
        v.compare_exchange(
            MaybeUninit::new(5),
            MaybeUninit::new(10),
            Ordering::Acquire,
            Ordering::Relaxed
        )
        .unwrap()
        .assume_init(),
        5
    );
    assert_eq!(v.load(Ordering::Relaxed).assume_init(), 10);

    assert_eq!(
        v.compare_exchange(
            MaybeUninit::new(6),
            MaybeUninit::new(12),
            Ordering::SeqCst,
            Ordering::Acquire
        )
        .unwrap_err()
        .assume_init(),
        10
    );
    assert_eq!(v.load(Ordering::Relaxed).assume_init(), 10);
}

pub fn compare_exchange_weak( &self, current: MaybeUninit<T>, new: MaybeUninit<T>, success: Ordering, failure: Ordering, ) -> Result<MaybeUninit<T>, MaybeUninit<T>>

where T: AtomicCompareExchange,

Stores a value into the atomic value if the current value is the same as the current value. Here, “the same” is determined using byte-wise equality, not PartialEq.

This function is allowed to spuriously fail even when the comparison succeeds, which can result in more efficient code on some platforms. The return value is a result indicating whether the new value was written and containing the previous value.

compare_exchange_weak takes two Ordering arguments to describe the memory ordering of this operation. success describes the required ordering for the read-modify-write operation that takes place if the comparison with current succeeds. failure describes the required ordering for the load operation that takes place when the comparison fails. Using Acquire as success ordering makes the store part of this operation Relaxed, and using Release makes the successful load Relaxed. The failure ordering can only be SeqCst, Acquire or Relaxed.

Panics

Panics if failure is Release, AcqRel.

Notes

Comparison of two values containing uninitialized bytes may fail even if they are equivalent as Rust’s type, because values can be byte-wise inequal even when they are equal as Rust values.

See compare_exchange for details.

Examples

use std::{mem::MaybeUninit, sync::atomic::Ordering};

use atomic_maybe_uninit::AtomicMaybeUninit;

let v = AtomicMaybeUninit::from(5_i32);

unsafe {
    let mut old = v.load(Ordering::Relaxed);
    loop {
        let new = old.assume_init() * 2;
        match v.compare_exchange_weak(
            old,
            MaybeUninit::new(new),
            Ordering::SeqCst,
            Ordering::Relaxed,
        ) {
            Ok(_) => break,
            Err(x) => old = x,
        }
    }
}

pub fn fetch_update<F>( &self, set_order: Ordering, fetch_order: Ordering, f: F, ) -> Result<MaybeUninit<T>, MaybeUninit<T>>

where F: FnMut(MaybeUninit<T>) -> Option<MaybeUninit<T>>, T: AtomicCompareExchange,

👎Deprecated:

renamed to try_update for consistency

An alias for try_update.

pub fn try_update( &self, set_order: Ordering, fetch_order: Ordering, f: impl FnMut(MaybeUninit<T>) -> Option<MaybeUninit<T>>, ) -> Result<MaybeUninit<T>, MaybeUninit<T>>

where T: AtomicCompareExchange,

Fetches the value, and applies a function to it that returns an optional new value. Returns a Result of Ok(previous_value) if the function returned Some(_), else Err(previous_value). See also: update.

Note: This may call the function multiple times if the value has been changed from other threads in the meantime, as long as the function returns Some(_), but the function will have been applied only once to the stored value.

try_update takes two Ordering arguments to describe the memory ordering of this operation. The first describes the required ordering for when the operation finally succeeds while the second describes the required ordering for loads. These correspond to the success and failure orderings of compare_exchange respectively.

Using Acquire as success ordering makes the store part of this operation Relaxed, and using Release makes the final successful load Relaxed. The (failed) load ordering can only be SeqCst, Acquire or Relaxed.

Panics

Panics if fetch_order is Release, AcqRel.

Considerations

This method is not magic; it is not provided by the hardware, and does not act like a critical section or mutex.

It is implemented on top of an atomic compare-and-swap operation, and thus is subject to the usual drawbacks of CAS operations. In particular, be careful of the ABA problem if this atomic integer is an index or more generally if knowledge of only the bitwise value of the atomic is not in and of itself sufficient to ensure any required preconditions.

Examples

use std::{mem::MaybeUninit, sync::atomic::Ordering};

use atomic_maybe_uninit::AtomicMaybeUninit;

unsafe {
    let v = AtomicMaybeUninit::from(5_i32);
    assert_eq!(
        v.try_update(Ordering::SeqCst, Ordering::SeqCst, |_| None).unwrap_err().assume_init(),
        5
    );
    assert_eq!(
        v.try_update(Ordering::SeqCst, Ordering::SeqCst, |x| Some(MaybeUninit::new(
            x.assume_init() + 1
        )))
        .unwrap()
        .assume_init(),
        5
    );
    assert_eq!(v.load(Ordering::SeqCst).assume_init(), 6);
}

pub fn update( &self, set_order: Ordering, fetch_order: Ordering, f: impl FnMut(MaybeUninit<T>) -> MaybeUninit<T>, ) -> MaybeUninit<T>

where T: AtomicCompareExchange,

Fetches the value, applies a function to it that it return a new value. The new value is stored and the old value is returned. See also: try_update.

Note: This may call the function multiple times if the value has been changed from other threads in the meantime, but the function will have been applied only once to the stored value.

update takes two Ordering arguments to describe the memory ordering of this operation. The first describes the required ordering for when the operation finally succeeds while the second describes the required ordering for loads. These correspond to the success and failure orderings of compare_exchange respectively.

Using Acquire as success ordering makes the store part of this operation Relaxed, and using Release makes the final successful load Relaxed. The (failed) load ordering can only be SeqCst, Acquire or Relaxed.

Panics

Panics if fetch_order is Release, AcqRel.

Considerations

This method is not magic; it is not provided by the hardware, and does not act like a critical section or mutex.

It is implemented on top of an atomic compare-and-swap operation, and thus is subject to the usual drawbacks of CAS operations. In particular, be careful of the ABA problem if this atomic integer is an index or more generally if knowledge of only the bitwise value of the atomic is not in and of itself sufficient to ensure any required preconditions.

Examples

use std::{mem::MaybeUninit, sync::atomic::Ordering};

use atomic_maybe_uninit::AtomicMaybeUninit;

unsafe {
    let v = AtomicMaybeUninit::from(5_i32);
    assert_eq!(
        v.update(Ordering::SeqCst, Ordering::SeqCst, |x| MaybeUninit::new(x.assume_init() + 1))
            .assume_init(),
        5
    );
    assert_eq!(
        v.update(Ordering::SeqCst, Ordering::SeqCst, |x| MaybeUninit::new(x.assume_init() + 1))
            .assume_init(),
        6
    );
    assert_eq!(v.load(Ordering::SeqCst).assume_init(), 7);
}

pub const fn as_ptr(&self) -> *mut MaybeUninit<T>

Returns a mutable pointer to the underlying value.

Doing non-atomic reads and writes on the resulting value can be a data race. This method is mostly useful for FFI, where the function signature may use *mut T instead of &AtomicMaybeUninit<T>.

Returning an *mut pointer from a shared reference to this atomic is safe because the atomic types work with interior mutability. All modifications of an atomic change the value through a shared reference, and can do so safely as long as they use atomic operations. Any use of the returned raw pointer requires an unsafe block and still has to uphold the requirements of the memory model.

impl AtomicMaybeUninit<i8>

pub const fn const_new(v: MaybeUninit<i8>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<u8>

pub const fn const_new(v: MaybeUninit<u8>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<i16>

pub const fn const_new(v: MaybeUninit<i16>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<u16>

pub const fn const_new(v: MaybeUninit<u16>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<i32>

pub const fn const_new(v: MaybeUninit<i32>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<u32>

pub const fn const_new(v: MaybeUninit<u32>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<i64>

pub const fn const_new(v: MaybeUninit<i64>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<u64>

pub const fn const_new(v: MaybeUninit<u64>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<i128>

pub const fn const_new(v: MaybeUninit<i128>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<u128>

pub const fn const_new(v: MaybeUninit<u128>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<isize>

pub const fn const_new(v: MaybeUninit<isize>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

impl AtomicMaybeUninit<usize>

pub const fn const_new(v: MaybeUninit<usize>) -> Self

👎Deprecated since 0.3.10:

use new instead because it is now always const fn

Creates a new atomic value from a potentially uninitialized value.

Trait Implementations

impl<T: Primitive> Debug for AtomicMaybeUninit<T>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<T: Primitive> From<MaybeUninit<T>> for AtomicMaybeUninit<T>

fn from(v: MaybeUninit<T>) -> Self

Creates a new atomic value from a potentially uninitialized value.

impl<T: Primitive> From<T> for AtomicMaybeUninit<T>

fn from(v: T) -> Self

Creates a new atomic value from an initialized value.

impl<T: Primitive> RefUnwindSafe for AtomicMaybeUninit<T>

impl<T: Primitive> Sync for AtomicMaybeUninit<T>