Tracking Issue for generic `Atomic`
CAD97 opened this issue · 4 comments
Feature gate: #![feature(generic_atomic)]
This is a tracking issue for replacing the distinct Atomic* types with a generic Atomic<T> type. This allows using Atomic with FFI type aliases and helps clean up some API surface. Only types with existing AtomicT are usable in Atomic<T>.
Public API
// core::sync::atomic
pub struct Atomic<T: AtomicPrimitive>(/* private fields*/);
pub type AtomicI32 = Atomic<i32>; // etcSteps / History
- ACP: rust-lang/libs-team#443
- Implement
Atomic<T>as an alias toAtomicT: #130543 - Flip alias so
AtomicTis an alias toAtomic<T> - Move generic functionality from
AtomicTtoAtomic<_> - Pseudo-prerequisite: Stabilize 128-bit atomics: #99069
- Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
Atomic<T>is soft-blocked on 128-bit atomics, because since trait implementations cannot be unstable, gatingAtomic<i128>separately fromAtomic<i32>isn't possible.- If necessary,
AtomicI128could instead nameAtomic<Wrapper<i128>>for some unstable nameWrapperuntil 128-bit atomics are stable, to preventAtomic<i128>from being usable from stable earlier than intended.
- If necessary,
Footnotes
Would/could this allow Atomic<(*const (), u64)>?
Not in the initial implementation tracked here, which does not aim to extend the set of types usable atomically yet. In the future, yes, this moves us into the direction of being able to support additional atomic types in the API.
From the ACP
impl<T> Unpin for Atomic<T> {}
This is surprising to me, why does this not propagate the Unpinness of T?
Why not propagate
Unpin
In this case, because I was overly terse laying out the API in the ACP, apparently. Both the NonZero code I was basing general structure off of and my local sketch do actually bound the autotrait impls on T: AutoTrait.
But also,
- The initial set of allowed types are all
Unpin. - It seems fundamentally impossible to use the atomic load/store/swap API with pinned data.