Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to handle uninitialized memory within portable-atomic #116

Open
notgull opened this issue Aug 13, 2023 · 4 comments
Open

Add a way to handle uninitialized memory within portable-atomic #116

notgull opened this issue Aug 13, 2023 · 4 comments
Labels
C-enhancement Category: A new feature or an improvement for an existing one

Comments

@notgull
Copy link
Contributor

notgull commented Aug 13, 2023

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.

@taiki-e
Copy link
Owner

taiki-e commented Aug 14, 2023

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.

@taiki-e taiki-e added C-enhancement Category: A new feature or an improvement for an existing one S-blocked Status: Blocked on something else labels Aug 14, 2023
@notgull
Copy link
Contributor Author

notgull commented Apr 23, 2024

It looks like the PR mentioned above has been merged into Rust v1.74.

@taiki-e taiki-e removed the S-blocked Status: Blocked on something else label Apr 23, 2024
@taiki-e
Copy link
Owner

taiki-e commented Oct 20, 2024

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.)

@notgull
Copy link
Contributor Author

notgull commented Dec 8, 2024

Hmm, maybe we disable CAS for platforms that don't work with it, like we do for architectures that don't have CAS support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: A new feature or an improvement for an existing one
Projects
None yet
Development

No branches or pull requests

2 participants