rust-lang/rust

Tracking Issue for generic `Atomic`

CAD97 opened this issue · 4 comments

CAD97 commented

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>; // etc

Steps / History

  • ACP: rust-lang/libs-team#443
  • Implement Atomic<T> as an alias to AtomicT: #130543
  • Flip alias so AtomicT is an alias to Atomic<T>
  • Move generic functionality from AtomicT to Atomic<_>
  • 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, gating Atomic<i128> separately from Atomic<i32> isn't possible.
    • If necessary, AtomicI128 could instead name Atomic<Wrapper<i128>> for some unstable name Wrapper until 128-bit atomics are stable, to prevent Atomic<i128> from being usable from stable earlier than intended.

Footnotes

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

cynecx commented

Would/could this allow Atomic<(*const (), u64)>?

CAD97 commented

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?

CAD97 commented

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.