Uh oh!
There was an error while loading. Please reload this page.
update 'allocation' docs with memory atomicity requirement - #158586
Conversation
rustbot
commented
Jun 29, 2026
|
rustbot
commented
Jun 29, 2026
|
| //! primitives. If atomics are enabled for a target, all allocations in writeable memory must | ||
| //! support all atomic operations. The precise instructions used for atomic operations are |
There was a problem hiding this comment.
| //! primitives. If atomics are enabled for a target, all allocations in writeable memory must | |
| //! support all atomic operations. The precise instructions used for atomic operations are | |
| //! primitives. Allocations must support all atomic operations that are available for a target (as determined by the `target_has_atomic*` cfg flags). | |
| //! The precise instructions used for atomic operations are |
Let's leave the discussion of immutable allocations to a future PR.
There was a problem hiding this comment.
The module level docs for std::sync::atomic already specify that memory must be writeable for atomics, if that changes anything. https://doc.rust-lang.org/std/sync/atomic/#atomic-accesses-to-read-only-memory
I like the rephrasing though, will use that
There was a problem hiding this comment.
The only way to get a non-writable Rust allocation is by impl Freeze statics (or promoted const).
It is still allowed to do atomic loads from this memory, AIUI, so all Rust allocations need to support being read with synchronization. For a write to this memory, that throws UB for writing without mutable provenance independent of the implementation memory supporting that write.
In other words, all allocations support atomic accesses. Using memory that cannot be written (atomically or otherwise) is a valid optimization when the memory is known to not be written to (e.g. when an attempted write would be UB).
There was a problem hiding this comment.
The docs I linked explicitly say that even loads may not always be valid on read-only memory. There are specific exceptions for specific target and sizes where the compiler guarantees it will generate loads suitable for read only memory.
There was a problem hiding this comment.
It's not just an optimization. The concept of an immutable allocation exists as a primitive in the AM, in my eyes. That's what the aforementioned atomic docs are implicitly referring to. We should update the "allocation" docs to make that explicit -- in a future PR.
RalfJung
commented
Jun 30, 2026
I view this as just a clarification so I don't think this needs FCP, but pinging @rust-lang/opsem @rust-lang/lang for your information. |
CAD97
commented
Jun 30, 2026
I agree that this is just a clarification of preexisting requirements for Rust allocations to behave consistently. |
RalfJung
commented
Jul 17, 2026
@rustbot author |
rustbot
commented
Jul 17, 2026
Reminder, once the PR becomes ready for a review, use |
890d991 to
d6f359bCompareasquared31415
commented
Jul 17, 2026
oops, this pr fell off the radar, ty for the reminder @rustbot ready |
RalfJung
commented
Jul 17, 2026
Thanks! |
Rollup of 5 pull requests Successful merges: - #159164 ([cg_ssa] Eliminate the `is_backend_{immediate,scalar_pair,ref}` methods) - #159175 (add a fallback for more `f16` intrinsics ) - #158586 (update 'allocation' docs with memory atomicity requirement) - #159390 (rustc: Avoid passing jobserver proxy around the compiler) - #159468 (Android platform support: add links to make it easier to figure out the supported API levels)
Uh oh!
There was an error while loading. Please reload this page.
Rollup merge of #158586 - asquared31415:ptr_alloc_atomic_docs, r=RalfJung update 'allocation' docs with memory atomicity requirement r? @RalfJung As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Region-based.20Atomic.20Capabilities/near/607225972)
r? @RalfJung
As discussed on zulip