* Kent Overstreet (kent.overstreet@xxxxxxxxx) wrote: > 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). That's quite architecturally specific isn't it? Or is this the distinction between accesses that are implicitly atomic (i.e. naturally aligned word) and things that are locked/exclusive? (either with a 'lock' on x86 or load-exclusive/store exclusive on some others)? Which are we talking about here? > 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. OK, so that's essentially the opposite worry of what I was saying; I was worrying about people forgetting to use an atomic access to a shared variable; I think you're worrying about people forgetting to mark a variable shared and since the accesses are the same nothing shouts? Dave -- -----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 |_______/
