Include racy reads in Rust memory model with `MaybeInvalid<T>`

RalfJung:

Making the kind of access a property of the location is a mistake that C made that we won't repeat -- there's no "atomic location", no "volatile location", and so also no "location that permits racy reads".

I am not suggesting at any point that we have a "location for which reads are racy by default". I do think it makes sense to have "location that permits explicitly performing racy read operations", so that writers know that's a possibility to account for, even if not every reader does it.

I also think, for instance, Rcu<T> makes sense, rather than having that be solely a property of the operation.

RalfJung:

So I think you are suggesting we should introduce a new kind of read that has these semantics

If by "these semantics" you mean

RalfJung:

racy reads return undef. undef is a value where if the program behavior ever depends on what the value is, that's UB.

then I'd need to know more about what that implies before agreeing that's a sensible model. For instance, does "dereference the pointer" count as "program behavior ever depends on what the value is"?

The kind of thing I'd like to be able to build in Rust, and can build today in C, is the kind of data structure I wrote my dissertation and other papers on, where writers can overwrite a pointer to a struct with a pointer to another instance of the same struct, and readers will get the old or new pointer, until an operation occurs that waits for all existing readers to finish, at which point it's safe to assume that new readers cannot get the old pointer (and thus, for instance, it could be freed or reused).

There have been whole memory models built for RCU atop weak memory ordering models, including various formalizations and proofs. And, importantly, people were using RCU before that , too.