On Mar 25, 2024, at 8:49 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
