On Tue, Mar 26, 2024 at 12:05:48AM +0000, Dr. David Alan Gilbert wrote: > * Linus Torvalds (torvalds@xxxxxxxxxxxxxxxxxxxx) wrote: > > <snip> > > > IOW, the whole access size problem that Boqun described is > > *inherently* tied to the fact that the C++ and Rust memory model is > > badly designed from the wrong principles. > > > > Instead of designing it as a "this is an atomic object that you can do > > these operations on", it should have been "this is an atomic access, > > and you can use this simple object model to have the compiler generate > > the accesses for you". > > Isn't one of the aims of the Rust/C++ idea that you can't forget to access > a shared piece of data atomically? > > If you want to have 'atomic accesses' explicitly, how do you tell the compiler > what you can use them on, and when it should stop you mixing them with > normal accesses on the same object? "can't forget to access data atomically" - that's only half of it. And atomic accesses loads/stores are not a thing under the hood, they're just loads and stores (possibly, but not necessarily, with memory barriers). The other half is at the _source_ level you don't want to treat accesses to volatiles/atomics like accesses to normal variables, you really want those to be explicit, and not look like normal variable accesses. std:atomic_int is way better than volatile in the sense that it's not a barely specified mess, but adding operator overloading was just gratuitious and unnecessary. This is a theme with C++ - they add a _ton_ of magic to make things concise and pretty, but you have to understand in intimate detail what all that magic is doing or you're totally fucked. std::atomic_int makes it such that just changing a single line of code in a single location in your program will change the semantics of your _entire_ program and the only obserable result will be that it's faster but a ticking time bomb because you just introduced a ton of races. With Rust - I honestly haven't looked at whether they added operator overlaoding for their atomics, but it's _much_ less of a concern because changing the type to the non-atomic version means your program won't compile if it's now racy.
