-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 Atomic*::from_mut_slice #94384
Add Atomic*::from_mut_slice #94384
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
Generally makes sense to me, though feels a bit unfortunate that we need a separate function - it seems like if you have stateless &mut T -> &mut U, you can do &mut [T] -> &mut [U], right? Probably not worth not doing this, but it feels like maybe there's a missing abstraction of some kind here - feels similar to https://doc.rust-lang.org/nightly/std/cell/struct.Cell.html#method.as_slice_of_cells in some ways. r? @dtolnay for libs-api sign off |
Yes, the constraint is almost like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
@bors r+ |
📌 Commit d3d2a27 has been approved by |
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. just like |
@WaffleLapkin that's a bit awkward because I don't think we can have a |
For me an explicit associated method seems fine. Can make a PR 👀 |
…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: ```rust // 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?
Tracking issue #76314 for
from_mut
has a question about the possibility offrom_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. Usingfrom_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