|
87 | 87 | //! atomic `load`s might be implemented using compare-exchange operations, even a `load` can fault
|
88 | 88 | //! on read-only memory.
|
89 | 89 | //!
|
90 |
| -//! (For the purpose of this section, "read-only memory" is defined as memory that is read-only in |
| 90 | +//! For the purpose of this section, "read-only memory" is defined as memory that is read-only in |
91 | 91 | //! the underlying target, i.e., the pages are mapped with a read-only flag and any attempt to write
|
92 | 92 | //! will cause a page fault. In particular, an `&u128` reference that points to memory that is
|
93 | 93 | //! read-write mapped is *not* considered to point to "read-only memory". In Rust, almost all memory
|
94 | 94 | //! is read-write; the only exceptions are memory created by `const` items or `static` items without
|
95 | 95 | //! interior mutability, and memory that was specifically marked as read-only by the operating
|
96 |
| -//! system via platform-specific APIs.) |
| 96 | +//! system via platform-specific APIs. |
97 | 97 | //!
|
98 |
| -//! However, as an exception from this general rule, "sufficiently small" atomic loads are |
99 |
| -//! implemented in a way that works on read-only memory. The exact threshold for what makes a load |
100 |
| -//! "sufficiently small" varies depending on the architecture and feature flags, but Rust guarantees |
101 |
| -//! that atomic loads that do not exceed the size documented in the following table are guaranteed |
102 |
| -//! to be read-only: |
| 98 | +//! As an exception from the general rule stated above, "sufficiently small" atomic loads with |
| 99 | +//! `Ordering::Relaxed` are implemented in a way that works on read-only memory, and are hence not |
| 100 | +//! Undefined Behavior. The exact size limit for what makes a load "sufficiently small" varies |
| 101 | +//! depending on the target: |
103 | 102 | //!
|
104 |
| -//! | Target architecture | Atomic loads no larger than this are guaranteed read-only | |
| 103 | +//! | Target triple prefix (regular expression) | Size limit | |
105 | 104 | //! |---------------|---------|
|
106 |
| -//! | `x86` | 4 bytes | |
107 |
| -//! | `x86_64` | 8 bytes | |
108 |
| -//! | `arm` | 4 bytes | |
109 |
| -//! | `aarch64` | 8 bytes | |
110 |
| -//! | `riscv32` | 4 bytes | |
111 |
| -//! | `riscv64` | 8 bytes | |
112 |
| -//! | `powerpc64` | 8 bytes | |
| 105 | +//! | `i(3|5|6)86-`, `arm`, `thumb`, `mips(|el)-`, `powerpc-`, `riscv32`, `sparc-` | 4 bytes | |
| 106 | +//! | `x86_64-`, `aarch64-`, `loongarch64-`, `mips64(|el)-`, `powerpc64-`, `riscv64` | 8 bytes | |
| 107 | +//! | `powerpc64le-` | 16 bytes | |
| 108 | +//! | `s390x-` | 16 bytes | |
113 | 109 | //!
|
114 |
| -//! Atomics loads that are larger than this threshold (and *all* atomic loads on targets not listed |
115 |
| -//! in the table) might still be read-only under certain conditions, but that is not a stable |
116 |
| -//! guarantee and should not be relied upon. |
| 110 | +//! Atomics loads that are larger than this limit as well as atomic loads with ordering other |
| 111 | +//! than `Relaxed`, as well as *all* atomic loads on targets not listed in the table, might still be |
| 112 | +//! read-only under certain conditions, but that is not a stable guarantee and should not be relied |
| 113 | +//! upon. |
117 | 114 | //!
|
118 | 115 | //! # Examples
|
119 | 116 | //!
|
|
0 commit comments