Type Alias AtomicPtr 

pub type AtomicPtr<T> = Atomic<*mut T>;

A raw pointer type which can be safely shared between threads.

This type has the same size and bit validity as a *mut T.

Note: This type is only available on platforms that support atomic loads and stores of pointers. Its size depends on the target pointer’s size.

Aliased Type

pub struct AtomicPtr<T> { /* private fields */ }

Implementations

impl<T> AtomicPtr<T>

pub const fn new(p: *mut T) -> AtomicPtr<T>

Creates a new AtomicPtr.

Examples

use std::sync::atomic::AtomicPtr;

let ptr = &mut 5;
let atomic_ptr = AtomicPtr::new(ptr);

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

Creates a new AtomicPtr from a pointer.

Examples

use std::sync::atomic::{self, AtomicPtr};

// Get a pointer to an allocated value
let ptr: *mut *mut u8 = Box::into_raw(Box::new(std::ptr::null_mut()));

assert!(ptr.cast::<AtomicPtr<u8>>().is_aligned());

{
    // Create an atomic view of the allocated value
    let atomic = unsafe { AtomicPtr::from_ptr(ptr) };

    // Use `atomic` for atomic operations, possibly share it with other threads
    atomic.store(std::ptr::NonNull::dangling().as_ptr(), atomic::Ordering::Relaxed);
}

// It's ok to non-atomically access the value behind `ptr`,
// since the reference to the atomic ended its lifetime in the block above
assert!(!unsafe { *ptr }.is_null());

// Deallocate the value
unsafe { drop(Box::from_raw(ptr)) }

Safety

• ptr must be aligned to align_of::<AtomicPtr<T>>() (note that on some platforms this can be bigger than align_of::<*mut 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 from_ptr_raw(ptr: *mut *mut T) -> *const AtomicPtr<T>

🔬This is a nightly-only experimental API. (atomic_volatile #158947)

Creates a new pointer to AtomicPtr from a pointer.

This is useful if you want to do volatile atomic accesses, and thus avoid creating a reference to the destination.

pub const fn null() -> AtomicPtr<T>

🔬This is a nightly-only experimental API. (atomic_ptr_null #150733)

Creates a new AtomicPtr initialized with a null pointer.

Examples

#![feature(atomic_ptr_null)]
use std::sync::atomic::{AtomicPtr, Ordering};

let atomic_ptr = AtomicPtr::<()>::null();
assert!(atomic_ptr.load(Ordering::Relaxed).is_null());

pub fn get_mut(&mut self) -> &mut *mut T

Returns a mutable reference to the underlying pointer.

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

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let mut data = 10;
let mut atomic_ptr = AtomicPtr::new(&mut data);
let mut other_data = 5;
*atomic_ptr.get_mut() = &mut other_data;
assert_eq!(unsafe { *atomic_ptr.load(Ordering::SeqCst) }, 5);

pub fn from_mut(v: &mut *mut T) -> &mut Self

Gets atomic access to a pointer.

Note: This function is only available on targets where AtomicPtr<T> has the same alignment as *const T

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let mut data = 123;
let mut some_ptr = &mut data as *mut i32;
let a = AtomicPtr::from_mut(&mut some_ptr);
let mut other_data = 456;
a.store(&mut other_data, Ordering::Relaxed);
assert_eq!(unsafe { *some_ptr }, 456);

pub fn get_mut_slice(this: &mut [Self]) -> &mut [*mut T]

Gets non-atomic access to a &mut [AtomicPtr] slice.

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

Examples

use std::ptr::null_mut;
use std::sync::atomic::{AtomicPtr, Ordering};

let mut some_ptrs = [const { AtomicPtr::new(null_mut::<String>()) }; 10];

let view: &mut [*mut String] = AtomicPtr::get_mut_slice(&mut some_ptrs);
assert_eq!(view, [null_mut::<String>(); 10]);
view
    .iter_mut()
    .enumerate()
    .for_each(|(i, ptr)| *ptr = Box::into_raw(Box::new(format!("iteration#{i}"))));

std::thread::scope(|s| {
    for ptr in &some_ptrs {
        s.spawn(move || {
            let ptr = ptr.load(Ordering::Relaxed);
            assert!(!ptr.is_null());

            let name = unsafe { Box::from_raw(ptr) };
            println!("Hello, {name}!");
        });
    }
});

pub fn from_mut_slice(v: &mut [*mut T]) -> &mut [Self]

Gets atomic access to a slice of pointers.

Note: This function is only available on targets where AtomicPtr<T> has the same alignment as *const T

Examples

use std::ptr::null_mut;
use std::sync::atomic::{AtomicPtr, Ordering};

let mut some_ptrs = [null_mut::<String>(); 10];
let a = &*AtomicPtr::from_mut_slice(&mut some_ptrs);
std::thread::scope(|s| {
    for i in 0..a.len() {
        s.spawn(move || {
            let name = Box::new(format!("thread{i}"));
            a[i].store(Box::into_raw(name), Ordering::Relaxed);
        });
    }
});
for p in some_ptrs {
    assert!(!p.is_null());
    let name = unsafe { Box::from_raw(p) };
    println!("Hello, {name}!");
}

pub const fn into_inner(self) -> *mut 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 std::sync::atomic::AtomicPtr;

let mut data = 5;
let atomic_ptr = AtomicPtr::new(&mut data);
assert_eq!(unsafe { *atomic_ptr.into_inner() }, 5);

pub fn load(&self, order: Ordering) -> *mut T

Loads a value from the pointer.

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::{AtomicPtr, Ordering};

let ptr = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let value = some_ptr.load(Ordering::Relaxed);

pub const unsafe fn load_volatile(self: *const Self, order: Ordering) -> *mut T

🔬This is a nightly-only experimental API. (atomic_volatile #158947)

Perform a volatile atomic load from the pointer.

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

Volatile operations are intended to act on I/O memory. As such, they are considered externally observable events (just like syscalls, but less opaque), and are guaranteed to not be elided or reordered by the compiler across other externally observable events. With this in mind, there are two cases of usage that need to be distinguished:

• When a volatile operation is used for memory inside an allocation, it behaves exactly like load, except for the additional guarantee that it won’t be elided or reordered across other externally observable events (see above). This implies that the operation will actually access memory and not e.g. be lowered to reusing data from a previous load. Other than that, all the usual rules for memory accesses apply (including provenance).

• Volatile operations, however, may also be used to access memory that is outside of any Rust allocation. In this use-case, the pointer does not have to be valid for reads. This is typically used for CPU and peripheral registers that must be accessed via an I/O memory mapping, most commonly at fixed addresses reserved by the hardware. These often have special semantics associated to their manipulation, and cannot be used as general purpose memory. Here, any address value is possible, including 0 and usize::MAX, so long as the semantics of such a read are well-defined by the target hardware. The provenance of the pointer is irrelevant, and it can be created with without_provenance. The access must not trap. It can cause side-effects, but those must not affect Rust-allocated memory in any way.

In both cases, the access is also considered atomic with the given order. This allows synchronization with other threads or devices that share memory with this program.

When invoked during const evaluation, this behaves like a regular atomic load. In particular, such reads must always follow the first of the two cases above.

Safety

Behavior is undefined if any of the following conditions are violated:

• self must be valid for reads, or self must point to memory outside of all Rust allocations and reading from that memory must:

  • not trap, and
  • not cause any memory inside a Rust allocation to be modified.

• self must be aligned to align_of::<AtomicPtr<T>>() (note that on some platforms this can be bigger than align_of::<*mut T>()).

• Reading from self must produce a properly initialized value of type *mut T.

Panics

Panics if order is Release or AcqRel.

Examples

Assuming an MMIO region at MMIO_ADDR that belongs to a device with direct memory access, we may receive a buffer in shared memory from that device as follows:

#![feature(atomic_volatile)]
use std::sync::atomic::{fence, AtomicPtr, Ordering};
use std::ptr;

const MMIO_ADDR: *mut *mut u8 = ptr::without_provenance_mut(0xCAF0);
let atomic_ptr = AtomicPtr::<u8>::from_ptr_raw(MMIO_ADDR);

// Spin until we see a non-zero value.
let buf = 'buf: loop {
    let buf = unsafe { atomic_ptr.load_volatile(Ordering::Relaxed) };
    if !buf.is_null() {
        break 'buf buf;
    }
};
// Synchronize with the store whose value we just read.
// Note: a standard acquire fence may not be sufficient to synchronize with DMA devices.
// Depending on your target, you may have to use inline assembly to emit a special fence.
fence(Ordering::Acquire);

// Now process the data in `buf`.

pub fn store(&self, ptr: *mut T, order: Ordering)

Stores a value into the pointer.

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::sync::atomic::{AtomicPtr, Ordering};

let ptr = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let other_ptr = &mut 10;

some_ptr.store(other_ptr, Ordering::Relaxed);

pub const unsafe fn store_volatile( self: *const Self, ptr: *mut T, order: Ordering, )

🔬This is a nightly-only experimental API. (atomic_volatile #158947)

Performs a volatile atomic store into the pointer.

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

Volatile operations are intended to act on I/O memory. As such, they are considered externally observable events (just like syscalls), and are guaranteed to not be elided or reordered by the compiler across other externally observable events. With this in mind, there are two cases of usage that need to be distinguished:

• When a volatile operation is used for memory inside an allocation, it behaves exactly like store, except for the additional guarantee that it won’t be elided or reordered across other externally observable events (see above). This implies that the operation will actually access memory and not e.g. be lowered to a register access. Other than that, all the usual rules for memory accesses apply (including provenance).

• Volatile operations, however, may also be used to access memory that is outside of any Rust allocation. In this use-case, the pointer does not have to be valid for writes. This is typically used for CPU and peripheral registers that must be accessed via an I/O memory mapping, most commonly at fixed addresses reserved by the hardware. These often have special semantics associated to their manipulation, and cannot be used as general purpose memory. Here, any address value is possible, including 0 and usize::MAX, so long as the semantics of such a write are well-defined by the target hardware. The provenance of the pointer is irrelevant, and it can be created with without_provenance_mut. The access must not trap. It can cause side-effects, but those must not affect Rust-allocated memory in any way.

In both cases, the access is also considered atomic with the given order. This allows synchronization with other threads or devices that share memory with this program.

When invoked during const evaluation, this behaves like a regular atomic store. In particular, such reads must always follow the first of the two cases above.

Safety

Behavior is undefined if any of the following conditions are violated:

• self must be either valid for writes, or self must point to memory outside of all Rust allocations and writing to that memory must:

  • not trap, and
  • not cause any memory inside a Rust allocation to be modified.

• self must be aligned to align_of::<AtomicPtr<T>>() (note that on some platforms this can be bigger than align_of::<*mut T>()).

Panics

Panics if order is Acquire or AcqRel.

Examples

Assuming an MMIO region at MMIO_ADDR that belongs to a device with direct memory access, we may submit a buffer in shared memory to that device as follows:

#![feature(atomic_volatile)]
use std::sync::atomic::{fence, AtomicPtr, Ordering};
use std::ptr;

const MMIO_ADDR: *mut *mut u8 = ptr::without_provenance_mut(0xCAF0);
let atomic_ptr = AtomicPtr::<u8>::from_ptr_raw(MMIO_ADDR);

// Prepare some data for the DMA device.
let buf = get_dma_buffer();

// Ensure the other side can synchronize with the store we do below.
// Note: a standard release fence may not be sufficient to synchronize with DMA devices.
// Depending on your target, you may have to use inline assembly to emit a special fence.
fence(Ordering::Release);

unsafe { atomic_ptr.store_volatile(buf, Ordering::Relaxed) };

pub fn swap(&self, ptr: *mut T, order: Ordering) -> *mut T

Stores a value into the pointer, 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.

Note: This method is only available on platforms that support atomic operations on pointers.

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let ptr = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let other_ptr = &mut 10;

let value = some_ptr.swap(other_ptr, Ordering::Relaxed);

pub fn compare_and_swap( &self, current: *mut T, new: *mut T, order: Ordering, ) -> *mut T

👎Deprecated since 1.50.0:

Use compare_exchange or compare_exchange_weak instead

Stores a value into the pointer if the current value is the same as the current value.

The return value is always the previous value. If it is equal to current, then the value was updated.

compare_and_swap also takes an Ordering argument which describes the memory ordering of this operation. Notice that even when using AcqRel, the operation might fail and hence just perform an Acquire load, but not have Release semantics. Using Acquire makes the store part of this operation Relaxed if it happens, and using Release makes the load part Relaxed.

Note: This method is only available on platforms that support atomic operations on pointers.

Migrating to compare_exchange and compare_exchange_weak

compare_and_swap is equivalent to compare_exchange with the following mapping for memory orderings:

Original	Success	Failure
Relaxed	Relaxed	Relaxed
Acquire	Acquire	Acquire
Release	Release	Relaxed
AcqRel	AcqRel	Acquire
SeqCst	SeqCst	SeqCst

compare_and_swap and compare_exchange also differ in their return type. You can use compare_exchange(...).unwrap_or_else(|x| x) to recover the behavior of compare_and_swap, but in most cases it is more idiomatic to check whether the return value is Ok or Err rather than to infer success vs failure based on the value that was read.

During migration, consider whether it makes sense to use compare_exchange_weak instead. compare_exchange_weak is allowed to fail spuriously even when the comparison succeeds, which allows the compiler to generate better assembly code when the compare and swap is used in a loop.

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let ptr = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let other_ptr = &mut 10;

let value = some_ptr.compare_and_swap(ptr, other_ptr, Ordering::Relaxed);

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

Stores a value into the pointer if the current value is the same as the current value.

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.

Note: This method is only available on platforms that support atomic operations on pointers.

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let ptr = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let other_ptr = &mut 10;

let value = some_ptr.compare_exchange(ptr, other_ptr,
                                      Ordering::SeqCst, Ordering::Relaxed);

Considerations

compare_exchange is a compare-and-swap operation and thus exhibits the usual downsides of CAS operations. In particular, a load of the value followed by a successful compare_exchange with the previous load does not ensure that other threads have not changed the value in the interim. This is usually important when the equality check in the compare_exchange is being used to check the identity of a value, but equality does not necessarily imply identity. This is a particularly common case for pointers, as a pointer holding the same address does not imply that the same object exists at that address! In this case, compare_exchange can lead to the ABA problem.

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

Stores a value into the pointer if the current value is the same as the current value.

Unlike AtomicPtr::compare_exchange, 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.

Note: This method is only available on platforms that support atomic operations on pointers.

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let some_ptr = AtomicPtr::new(&mut 5);

let new = &mut 10;
let mut old = some_ptr.load(Ordering::Relaxed);
loop {
    match some_ptr.compare_exchange_weak(old, new, Ordering::SeqCst, Ordering::Relaxed) {
        Ok(_) => break,
        Err(x) => old = x,
    }
}

Considerations

compare_exchange is a compare-and-swap operation and thus exhibits the usual downsides of CAS operations. In particular, a load of the value followed by a successful compare_exchange with the previous load does not ensure that other threads have not changed the value in the interim. This is usually important when the equality check in the compare_exchange is being used to check the identity of a value, but equality does not necessarily imply identity. This is a particularly common case for pointers, as a pointer holding the same address does not imply that the same object exists at that address! In this case, compare_exchange can lead to the ABA problem.

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

where F: FnMut(*mut T) -> Option<*mut T>,

👎Deprecated since 1.99.0:

renamed to try_update for consistency

An alias for AtomicPtr::try_update.

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

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 AtomicPtr::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.

Note: This method is only available on platforms that support atomic operations on pointers.

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, which is a particularly common pitfall for pointers!

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let ptr: *mut _ = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let new: *mut _ = &mut 10;
assert_eq!(some_ptr.try_update(Ordering::SeqCst, Ordering::SeqCst, |_| None), Err(ptr));
let result = some_ptr.try_update(Ordering::SeqCst, Ordering::SeqCst, |x| {
    if x == ptr {
        Some(new)
    } else {
        None
    }
});
assert_eq!(result, Ok(ptr));
assert_eq!(some_ptr.load(Ordering::SeqCst), new);

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

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 AtomicPtr::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.

Note: This method is only available on platforms that support atomic operations on pointers.

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, which is a particularly common pitfall for pointers!

Examples

use std::sync::atomic::{AtomicPtr, Ordering};

let ptr: *mut _ = &mut 5;
let some_ptr = AtomicPtr::new(ptr);

let new: *mut _ = &mut 10;
let result = some_ptr.update(Ordering::SeqCst, Ordering::SeqCst, |_| new);
assert_eq!(result, ptr);
assert_eq!(some_ptr.load(Ordering::SeqCst), new);

pub fn fetch_ptr_add(&self, val: usize, order: Ordering) -> *mut T

Offsets the pointer’s address by adding val (in units of T), returning the previous pointer.

This is equivalent to using wrapping_add to atomically perform the equivalent of ptr = ptr.wrapping_add(val);.

This method operates in units of T, which means that it cannot be used to offset the pointer by an amount which is not a multiple of size_of::<T>(). This can sometimes be inconvenient, as you may want to work with a deliberately misaligned pointer. In such cases, you may use the fetch_byte_add method instead.

fetch_ptr_add 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let atom = AtomicPtr::<i64>::new(core::ptr::null_mut());
assert_eq!(atom.fetch_ptr_add(1, Ordering::Relaxed).addr(), 0);
// Note: units of `size_of::<i64>()`.
assert_eq!(atom.load(Ordering::Relaxed).addr(), 8);

pub fn fetch_ptr_sub(&self, val: usize, order: Ordering) -> *mut T

Offsets the pointer’s address by subtracting val (in units of T), returning the previous pointer.

This is equivalent to using wrapping_sub to atomically perform the equivalent of ptr = ptr.wrapping_sub(val);.

This method operates in units of T, which means that it cannot be used to offset the pointer by an amount which is not a multiple of size_of::<T>(). This can sometimes be inconvenient, as you may want to work with a deliberately misaligned pointer. In such cases, you may use the fetch_byte_sub method instead.

fetch_ptr_sub 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let array = [1i32, 2i32];
let atom = AtomicPtr::new(array.as_ptr().wrapping_add(1) as *mut _);

assert!(core::ptr::eq(
    atom.fetch_ptr_sub(1, Ordering::Relaxed),
    &array[1],
));
assert!(core::ptr::eq(atom.load(Ordering::Relaxed), &array[0]));

pub fn fetch_byte_add(&self, val: usize, order: Ordering) -> *mut T

Offsets the pointer’s address by adding val bytes, returning the previous pointer.

This is equivalent to using wrapping_byte_add to atomically perform ptr = ptr.wrapping_byte_add(val).

fetch_byte_add 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let atom = AtomicPtr::<i64>::new(core::ptr::null_mut());
assert_eq!(atom.fetch_byte_add(1, Ordering::Relaxed).addr(), 0);
// Note: in units of bytes, not `size_of::<i64>()`.
assert_eq!(atom.load(Ordering::Relaxed).addr(), 1);

pub fn fetch_byte_sub(&self, val: usize, order: Ordering) -> *mut T

Offsets the pointer’s address by subtracting val bytes, returning the previous pointer.

This is equivalent to using wrapping_byte_sub to atomically perform ptr = ptr.wrapping_byte_sub(val).

fetch_byte_sub 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let mut arr = [0i64, 1];
let atom = AtomicPtr::<i64>::new(&raw mut arr[1]);
assert_eq!(atom.fetch_byte_sub(8, Ordering::Relaxed).addr(), (&raw const arr[1]).addr());
assert_eq!(atom.load(Ordering::Relaxed).addr(), (&raw const arr[0]).addr());

pub fn fetch_or(&self, val: usize, order: Ordering) -> *mut T

Performs a bitwise “or” operation on the address of the current pointer, and the argument val, and stores a pointer with provenance of the current pointer and the resulting address.

This is equivalent to using map_addr to atomically perform ptr = ptr.map_addr(|a| a | val). This can be used in tagged pointer schemes to atomically set tag bits.

Caveat: This operation returns the previous value. To compute the stored value without losing provenance, you may use map_addr. For example: a.fetch_or(val).map_addr(|a| a | val).

fetch_or 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

This API and its claimed semantics are part of the Strict Provenance experiment, see the module documentation for ptr for details.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let pointer = &mut 3i64 as *mut i64;

let atom = AtomicPtr::<i64>::new(pointer);
// Tag the bottom bit of the pointer.
assert_eq!(atom.fetch_or(1, Ordering::Relaxed).addr() & 1, 0);
// Extract and untag.
let tagged = atom.load(Ordering::Relaxed);
assert_eq!(tagged.addr() & 1, 1);
assert_eq!(tagged.map_addr(|p| p & !1), pointer);

pub fn fetch_and(&self, val: usize, order: Ordering) -> *mut T

Performs a bitwise “and” operation on the address of the current pointer, and the argument val, and stores a pointer with provenance of the current pointer and the resulting address.

This is equivalent to using map_addr to atomically perform ptr = ptr.map_addr(|a| a & val). This can be used in tagged pointer schemes to atomically unset tag bits.

Caveat: This operation returns the previous value. To compute the stored value without losing provenance, you may use map_addr. For example: a.fetch_and(val).map_addr(|a| a & val).

fetch_and 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

This API and its claimed semantics are part of the Strict Provenance experiment, see the module documentation for ptr for details.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let pointer = &mut 3i64 as *mut i64;
// A tagged pointer
let atom = AtomicPtr::<i64>::new(pointer.map_addr(|a| a | 1));
assert_eq!(atom.fetch_or(1, Ordering::Relaxed).addr() & 1, 1);
// Untag, and extract the previously tagged pointer.
let untagged = atom.fetch_and(!1, Ordering::Relaxed)
    .map_addr(|a| a & !1);
assert_eq!(untagged, pointer);

pub fn fetch_xor(&self, val: usize, order: Ordering) -> *mut T

Performs a bitwise “xor” operation on the address of the current pointer, and the argument val, and stores a pointer with provenance of the current pointer and the resulting address.

This is equivalent to using map_addr to atomically perform ptr = ptr.map_addr(|a| a ^ val). This can be used in tagged pointer schemes to atomically toggle tag bits.

Caveat: This operation returns the previous value. To compute the stored value without losing provenance, you may use map_addr. For example: a.fetch_xor(val).map_addr(|a| a ^ val).

fetch_xor 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.

Note: This method is only available on platforms that support atomic operations on AtomicPtr.

This API and its claimed semantics are part of the Strict Provenance experiment, see the module documentation for ptr for details.

Examples

use core::sync::atomic::{AtomicPtr, Ordering};

let pointer = &mut 3i64 as *mut i64;
let atom = AtomicPtr::<i64>::new(pointer);

// Toggle a tag bit on the pointer.
atom.fetch_xor(1, Ordering::Relaxed);
assert_eq!(atom.load(Ordering::Relaxed).addr() & 1, 1);

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

Returns a mutable pointer to the underlying pointer.

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

Examples

use std::sync::atomic::AtomicPtr;

extern "C" {
    fn my_atomic_op(arg: *mut *mut u32);
}

let mut value = 17;
let atomic = AtomicPtr::new(&mut value);

// SAFETY: Safe as long as `my_atomic_op` is atomic.
unsafe {
    my_atomic_op(atomic.as_ptr());
}

Trait Implementations

impl<T> Debug for AtomicPtr<T>

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

Formats the value using the given formatter.

impl<T> Default for AtomicPtr<T>

fn default() -> AtomicPtr<T>

Creates a null AtomicPtr<T>.

impl<T> From<*mut T> for AtomicPtr<T>

fn from(p: *mut T) -> Self

Converts a *mut T into an AtomicPtr<T>.

impl<T> Pointer for AtomicPtr<T>

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

Formats the value using the given formatter.

impl<T> RefUnwindSafe for AtomicPtr<T>