Skip to content

Commit e5186aa

Browse files
authored
Rollup merge of #121082 - peterjoel:atomic-docs, r=cuviper
Clarified docs on non-atomic oprations on owned/mut refs to atomics I originally misinterpreted the documentation to mean that the compiler can/will automatically optimise away atomic operations whenever the data is owned or mutably referenced. On re-reading I think it is not technically incorrect, but specifically mentioning _how_ the atomic operations can be avoided also prevents this misunderstanding.
2 parents f9a0675 + 9cccf20 commit e5186aa

File tree

1 file changed

+3
-2
lines changed

1 file changed

+3
-2
lines changed

library/core/src/sync/atomic.rs

+3-2
Original file line numberDiff line numberDiff line change
@@ -27,8 +27,9 @@
2727
//! Rust atomics currently follow the same rules as [C++20 atomics][cpp], specifically `atomic_ref`.
2828
//! Basically, creating a *shared reference* to one of the Rust atomic types corresponds to creating
2929
//! an `atomic_ref` in C++; the `atomic_ref` is destroyed when the lifetime of the shared reference
30-
//! ends. (A Rust atomic type that is exclusively owned or behind a mutable reference does *not*
31-
//! correspond to an "atomic object" in C++, since it can be accessed via non-atomic operations.)
30+
//! ends. A Rust atomic type that is exclusively owned or behind a mutable reference does *not*
31+
//! correspond to an “atomic object” in C++, since the underlying primitive can be mutably accessed,
32+
//! for example with `get_mut`, to perform non-atomic operations.
3233
//!
3334
//! [cpp]: https://en.cppreference.com/w/cpp/atomic
3435
//!

0 commit comments

Comments
 (0)