Messages in this thread | | | Subject | Re: [WIP 0/3] Memory model and atomic API in Rust | From | comex <> | Date | Wed, 27 Mar 2024 09:16:09 -0700 |
| |
On Mar 25, 2024, at 8:49 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> But you should _start_ the design of your language memory model around > the unsafe "raw atomic access operations" model. > > Then you can use those strictly more powerful operations, and you > create an object model *around* it.
To some extent Rust does this already, unlike C++.
C++ allows atomics to be implemented using locks. Partly for this reason, `std::atomic<T>` is documented as not necessarily having the same representation as `T` [1]. C++ also has strict aliasing, so even if those types do have the same representation, you still can't cast `T *` to `std::atomic<T> *`.
But Rust atomics are lower-level. First, they are guaranteed lock-free [2]. Second, they are documented as having "the same in-memory representation as the underlying" type [3]. (They also usually have the same alignment, except on x86 where u64 is only 4-byte aligned but AtomicU64 of course needs to be 8-byte aligned.) Meanwhile, Rust intentionally lacks strict aliasing.
Combined, this means it's perfectly legal in Rust to cast e.g. `&mut u32` to `&AtomicU32` and perform atomic accesses on it. Or the same with u64/AtomicU64 if you know the pointer is validly aligned. This is by design; the Atomic types' methods are considered the official way to perform atomic operations on arbitrary memory, making it unnecessary to also stabilize 'lower-level' intrinsics.
That said, there *are* currently some holes in Rust's atomics model, based on the fact that it's mostly inherited from C++. From the documentation:
> Since C++ does not support mixing atomic and non-atomic accesses, or > non-synchronized different-sized accesses to the same data, Rust does not > support those operations either. Note that both of those restrictions only > apply if the accesses are non-synchronized. https://doc.rust-lang.org/std/sync/atomic/index.html
There are some open issues around this:
- "How can we allow read-read races between atomic and non-atomic accesses?" https://github.com/rust-lang/unsafe-code-guidelines/issues/483
> [..] I do think we should allow such code. However, then we have to change > the way we document our atomics [..]
- "What about: mixed-size atomic accesses" https://github.com/rust-lang/unsafe-code-guidelines/issues/345"
> Apparently the x86 manual says you "should" not do this [..] It is unclear > what "should" means (or what anything else here really means, operationally > speaking...)
[1] https://eel.is/c++draft/atomics#types.generic.general-3 [2] https://doc.rust-lang.org/std/sync/atomic/index.html#portability [3] https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicU64.html
| |