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

See if unordered atomics are a feasible replacement for DisjointMut's potential unsoundness #1359

Open
kkysen opened this issue Sep 17, 2024 · 0 comments
Labels
low priority Issues that we would like to address at some point in the future performance safety/correctness

Comments

@kkysen
Copy link
Collaborator

kkysen commented Sep 17, 2024

In a discussion of DisjointMut and its potential unsoundness (if there are any overlapping ranges in --release mode) on Reddit, u/afdbcreid suggested suggested Unordered atomics as a potential performant solution, as discussed on IRLO: unordered as a solution to “Bit-wise reasoning for atomic accesses”.

The only other potentially performant option we saw was to use Relaxed atomics. However, even Relaxed atomics are not optimized the same way in aggregate. An individual Relaxed load and store is the same instruction as a NotAtomic load and store, but, for example, 2 16-bit aligned AtomicU8 loads are not merged into a single AtomicU16 load. However, in LLVM's atomics model, there is a level between NotAtomic and Relaxed/Monotonic called Unordered. It is used by Java primarily and has even fewer guarantees compared to Relaxed/Monotonic, and as such, LLVM will do those same merging optimizations that we want. As such, it's possible it would result in good enough performance. However, Unordered is not in stable Rust, and is only an unstable intrinsic at the moment: good enough for some experimentation if we want to try it out, but far from stable. And fully trying it out, along with all of the necessary refactoring, and then evaluating performance would be significant work. Ideally, we'd try in the name of soundness, though time is a concern.

@kkysen kkysen added low priority Issues that we would like to address at some point in the future performance safety/correctness labels Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low priority Issues that we would like to address at some point in the future performance safety/correctness
Projects
None yet
Development

No branches or pull requests

1 participant