External Publication
Visit Post

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

Rust Internals [Unofficial] May 13, 2026
Source

josh:

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 don't really know what you mean by this. But location-based models typically just behave poorly, especially in Rust where we have operations like get_mut which allow "normal" non-atomic accesses to what otherwise look like "atomic locations".

josh:

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"?

I don't know which pointer you mean. But deref'ing an undef pointer is UB, yes. At this point I think we are entirely talking past each other though.

If you want to load a pointer in a way that allows races, we already have a way to do that: AtomicPtr::load (with Ordering::Relaxed if you want to get just a regular boring load instruction). This thread is about situations where the existing atomic APIs we have do not suffice, such as SeqLocks (which can be implemented neither in C nor Rust nor C++ at the moment; the intended way to fix that is atomic bytewise memcpy ).

RCU exists in many variants and at least some of them are entirely compatible with the C++ memory model and hence can already be implemented in Rust.

Discussion in the ATmosphere

Loading comments...