Tracking Issue for atomic_from_mut

[KodrAus]

Feature gate: #![feature(atomic_from_mut)]

Public API

impl AtomicU32 {
    pub fn from_mut(v: &mut u32) -> &mut Self;
    pub fn from_mut_slice(v: &mut [u32]) -> &mut [Self];
    pub fn get_mut_slice(this: &mut [Self]) -> &mut [u32];
}

// And same for AtomicBool, AtomicU8, AtomicU16, AtomicU64, AtomicI8, AtomicI16, AtomicI32, AtomicI64, and AtomicPtr

Each one is gated on #[cfg(target_has_atomic_equal_alignment = "..")] and is only available on platforms where Atomic<size> has the same alignment as u<size>.

Steps / History

• Implementation: Add Atomic*::from_mut. #74532
• Make Atomic*::from_mut return &mut Atomic* #92671
• Add Atomic*::from_mut_slice #94384
• Add Atomic*::get_mut_slice #94816
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Should these return &mut Self instead, such that it's the exact inverse of get_mut? — yes: Make Atomic*::from_mut return &mut Atomic* #92671
• Also add from_mut_slice? — yes: Add Atomic*::from_mut_slice #94384

[RalfJung]

For some types, these functions introduce a significant risk of accidentally writing non-portable code: when I am on x86_64, I might not realize that by calling AtomicU64::from_mut I am excluding platforms like x64_32 where u64 has alignment less than 8.

[m-ou-se]

But the same holds for the other atomics operations, right? Using 64-bit atomic cas operations will also exclude a lot of platforms.

The alternative is that people write this manually using transmute. That code will be equally non-portable, except it'll compile just fine and silently cause UB.

That said, it might be good to extend the note in the documentation to mention platforms like x86 and x64_32 specifically.

[RalfJung]

Yeah, I am not saying this is a blocker. This could be something that good documentation can solve.

[RustyYato]

Can Atomic*::from_mut's signature be changed to fn(&mut _) -> &mut Self instead of fn(&mut _) -> &Self. This way from_mut and get_mut are inverses. (I view Cell::from_mut's signature as a wart, that can't be fixed, but Atomic*::from_mut can be changed).

[m-ou-se]

@RustyYato Is there a use case for that? There's not much more you can do with a &mut Atomic other than get_mut().

[RustyYato]

@m-ou-se No specific use-case, it just seems odd to me that from_mut and get_mut are not inverses.

[m-ou-se]

Okay. I've added your suggestion to the unresolved questions to resolve before stabilizing this.

[the8472]

Should these return &mut Self instead, such that it's the exact inverse of get_mut?

I think the following two make sense.

• from_mut(&mut _) -> &mut Self, inverse of get_mut
• unsafe from_mut_ptr(*mut _) -> &Self, inverse of as_mut_ptr and does not allow get_mut

[biabeb]

unsafe from_mut_ptr(*mut _) -> &Self, inverse of as_mut_ptr and does not allow get_mut

What would be the safety requirements on from_mut_ptr? Would overlapping atomics of different sizes be alllowed?

Overlapping atomics of different sizes is probably an obscure use case, but it would be really helpful in some situations. However, Rust's memory model (i.e., C++ memory model) does not appear to account for that possibility.

[RalfJung]

Such overlapping atomics are called "mixed accesses" in the weak memory literature, and indeed most memory models do not support them.