You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to be able to handle uninitialized memory, like with the atomic-maybe-uninit crate. I'm not familiar enough with atomic instructions to know how this could be done.
The text was updated successfully, but these errors were encountered:
Once rust-lang/rust#114790 or an alternative is merged, it would be easy to extend the inline assemblies used in portable-atomic to work with MaybeUninit as well. Once that happens, I may start to consider merging atomic-maybe-uninit into portable-atomic.
I've been thinking about this, and while it would be okay if it were a generic atomic built on top of AtomicMaybeUninit (e.g., crossbeam-rs/crossbeam#1015) or something like AtomicDoublePtr (that could be supported without AtomicMaybeUninit within portable-atomic), I don't think it would be practical to fully support AtomicMaybeUninit itself in a portable way. (At least in the current Rust semantics or simple extension of it.)
The major problem is the difficulty of implementing fallback used in Miri, sanitizer, or any architecture where asm is not yet stable or does not exist. It is the comparison part in CAS that is problematic, and as discussed in UCG issue/zulip, it is very likely that an AtomicMaybeUninit without asm cannot handle real uninitialized bytes (initialized pointer with provenance is fine) in CAS. (At least in the current Rust semantics or simple extension of it.)
It would be nice to be able to handle uninitialized memory, like with the
atomic-maybe-uninit
crate. I'm not familiar enough with atomic instructions to know how this could be done.The text was updated successfully, but these errors were encountered: