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? > Well, you can just wrap it in your own atomic types, can't you? If the atomic primitives that a language provides is access-based, users can create their own atomic types or language can provide via standard library, but mixed usage is still allowed when it makes sense (debug functionality, low level concurrent code that utilizes races, etc.) But if the atomic primitives that a language provides is type-based, then you're limited to what you can do. It might be totally fine as Linus pointed out, if you just write a portable library, and don't want to care about architectural details. But that's not the case in Linux kernel. Regards, Boqun > Dave > > > This is why I claim that LKMM is fundamentally better. It didn't start > > out from a bass-ackwards starting point of marking objects "atomic". > > > > And yes, the LKMM is a bit awkward, because we don't have the > > shorthands, so you have to write out "atomic_read()" and friends. > > > > Tough. It's better to be correct than to be simple. > > > > Linus > > > -- > -----Open up your eyes, open up your mind, open up your code ------- > / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ > \ dave @ treblig.org | | In Hex / > \ _________________________|_____ http://www.treblig.org |_______/
