Zeroable should be implemented for `Atomic*`
eira-fransham opened this issue · 4 comments
The atomic types are all bytemuck-compatible, and in fact as far as I know all bytemuck traits can be implemented for Atomic* that can be implemented for the underlying integer type as the operations available on the atomic types are a strict superset (i.e. setting their value via an immutable reference). Even casting between a non-atomic int and an atomic int should be safe, although from this discussion here rust-lang/rust#76314 it may be invalid to cast an &usize (or other scalar) to an &AtomicUsize (or other atomic scalar). This sadly means that Pod cannot be implemented without adding new traits to account for types where owned types can be cast but references cannot.
If it's unsafe to cast &usize to &AtomicUsize then the AtomicUsize type doesn't fit with Pod, because Pod allows casting between &T and &U when the size and alignment match.
Similarly, the TransparentWrapper trait isn't appropriate.
It's fine to have Zeroable, I suppose.
I think it might make sense to have new traits for immutable access, since that would allow safe casts to/from Cell/UnsafeCell/Atomic*, but even just Zeroable would be enough since that would allow the parking_lot mutexes to be zeroable and therefore it would be possible to safely create a heap-allocated array of them using calloc using the helpers in this crate.
I'll put a PR in to implement Zeroable and leave splitting the traits to later, since it's not necessary right now.
I don't think you should read atomic values non-atomically.
Yeah, very good point. Well, at least zeroable should be implemented.