Add a generic CAS loop to std::sync::Atomic*
This adds two new methods to both `AtomicIsize` and `AtomicUsize` with optimized safe compare-and-set loops, so users will no longer need to write their own, except in *very* strange circumstances.
`update_and_fetch` will apply the function and return its result, whereas `fetch_and_update` will apply the function and return the previous value.
This solves #48384 with `x.update_and_fetch(|x| x.max(y))`. It also relates to #48655 (which I misuse as tracking issue for now)..
*note* This *might* need a crater run because the functions could clash with third party extension traits.
This adds a new method to all numeric `Atomic*` types with a
safe compare-and-set loop, so users will no longer need to write
their own, except in *very* strange circumstances.
This solves #48384 with `x.fetch_max(_)`/`x.fetch_min(_)`. It
also relates to #48655 (which I misuse as tracking issue for now).
*note* This *might* need a crater run because the functions could
clash with third party extension traits.
impl From<bool> for AtomicBool
This seems like an obvious omission from #45610. ~~I've used the same feature name and version in the hope that this can be backported to beta so it's stabilized with the other impls. If it can't be I'll change it to `1.24.0`.~~
This addresses concerns raised following the merge of #41092.
Specifically:
> The naming of these seems surprising: the multithreaded functions (and
> both the single and multithreaded intrinsics themselves) are fences,
> but this is a barrier. It's not incorrect, but the latter is both
> inconsistent with the existing functions and slightly confusing with
> another type in std (e.g., `Barrier`).
`compiler_fence` carries the same semantic implication that this is a
compiler-only operation, while being more in line with the fence/barrier
concepts already in use in `std`.
Add safe wrapper for atomic_compilerfence intrinsics
This PR adds a proposed safe wrapper for the `atomic_singlethreadfence_*` intrinsics introduced by [RFC #888](https://github.com/rust-lang/rfcs/pull/888). See #41091 for further discussion.
* Since the switch to pulldown-cmark reference links need a blank line
before the URLs.
* Reference link references are not case sensitive.
* Doc comments need to be indented uniformly otherwise rustdoc gets
confused.