Add Atomic*::from_mut_slice by cuviper · Pull Request #94384 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation10 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Tracking issue #76314 for from_mut has a question about the possibility of from_mut_slice, and I found a real case for it. A user in the forum had a parallelism problem that could be solved by open-indexing updates to a vector of atomics, but they didn't want to affect the other code using that vector. Using from_mut_slice, they could borrow that data as atomics just long enough for their parallel loop.
ref: https://users.rust-lang.org/t/sharing-vector-with-rayon-par-iter-correctly/72022
(rust-highfive has picked a reviewer for you, use r? to override)
it seems like if you have stateless &mut T -> &mut U, you can do &mut [T] -> &mut [U], right?
Yes, the constraint is almost like T: AsMut<U>, but they have to be the same size and return the same address, no dereferencing. It's similar to coercion too. Maybe something like unsafe trait CoerceMut<T> with a blanket impl for slices?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
📌 Commit d3d2a27 has been approved by dtolnay
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
Rollup of 7 pull requests
Successful merges:
- rust-lang#91545 (Generalize "remove
&" and "add*" suggestions to more than one deref) - rust-lang#93385 (Rustdoc ty consistency fixes)
- rust-lang#93926 (Lint against more useless
#[must_use]attributes) - rust-lang#94094 (use BOOL for TCP_NODELAY setsockopt value on Windows)
- rust-lang#94384 (Add Atomic*::from_mut_slice)
- rust-lang#94448 (5 - Make more use of
let_chains) - rust-lang#94452 (Sync portable-simd for bitmasks &c.)
Failed merges:
r? @ghost
@rustbot modify labels: rollup
:D Coincidentally I just got to my to do list item that says "Add atomic from_mut_slice" and noticed you just added it a few days ago. Nice!
Should we also introduce the inverse operation? i.e. &mut [Atomic*] -> &mut [*]?
just like Atomic*::from_mut has an inverse Atomic*::get_mut.
@WaffleLapkin that's a bit awkward because I don't think we can have a &mut [self] method. So it would either have to be a method on actual slice impls, or else an explicit associated method like Atomic*::get_mut_slice(this: &mut [Self]).
For me an explicit associated method seems fine. Can make a PR 👀
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…r=Mark-Simulacrum
Add Atomic*::get_mut_slice
This PR adds the inverse of Atomic*::from_mut_slice introduced in rust-lang#94384 with the following API:
// core::sync::atomic
impl Atomic* {
fn get_mut_slice(this: &mut [Self]) -> &mut [*];
}cc @cuviper
For now I've used the same tracking issue as Atomic*::from_mut_slice, should I open a new one?
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.