diff options
| author | Dylan DPC <99973273+Dylan-DPC@users.noreply.github.com> | 2022-03-01 03:41:51 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-03-01 03:41:51 +0100 |
| commit | 5bd119da844662082f28907ce84fa9f774716527 (patch) | |
| tree | 6f988dca80dad0f1e21f342725c80850718a0781 /compiler/rustc_codegen_llvm/src | |
| parent | 06d47a414bdf6be59fe8393fdd1ccb0247dce6f2 (diff) | |
| parent | d3d2a279fe7afa2c7f06c50ef5e70b8446bb68ee (diff) | |
| download | rust-5bd119da844662082f28907ce84fa9f774716527.tar.gz rust-5bd119da844662082f28907ce84fa9f774716527.zip | |
Rollup merge of #94384 - cuviper:atomic-slice, r=dtolnay
Add Atomic*::from_mut_slice 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
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions