Tracking Issue for atomic volatile operations (`atomic_volatile`)

[RalfJung]

Feature gate: #![feature(atomic_volatile)]

This is a tracking issue for atomic volatile operations

• ACP: ACP: add volatile operations to Atomic* types libs-team#801
• t-opsem approval for the general principle: Opsem extension proposal: atomic volatile accesses unsafe-code-guidelines#615

Public API

// Not actually a generic impl, but you get the idea.
impl Atomic<T> {
  /// Convenient method to create a raw pointer to `Atomic<T>` suitable for volatile accesses.  
  pub fn from_ptr_raw(ptr: *mut T) -> *const Self;

  /// Performs a volatile atomic load of the given `order`.
  pub unsafe fn load_volatile(self: *const Self, order: Ordering) -> T;
  /// Performs a volatile atomic store of the given `order`.
  pub unsafe fn store_volatile(self: *const Self, val: T, order: Ordering);
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: ACP: add volatile operations to Atomic* types libs-team#801
  • Since then, I renamed volatile_load to load_volatile to be consistent with the existing read_volatile that also makes volatile a suffix rather than a prefix (and same for stores)
• Implementation
  • atomic volatile: add intrinsics #160058
  • libcore: expose volatile atomic operations #161301
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Currently the API uses arbitrary_self_types_pointers. Are we okay with that or would it be bad to expose that on stable?
• On LLVM 22 and older, we don't correctly handle atomic volatile loads that trap. Adding the same black_box we add for non-atomic volatile loads is tricky because of how the code is structured in the backend. Maybe we should just wait until the minimum LLVM version is 23 before stabilizing this...

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩