{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihxyglagsrmklt3ehewyxnysdmsi55cqaoqtuqzcpwqte62dwlmtm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlmhltynna22"
  },
  "path": "/t/include-racy-reads-in-rust-memory-model-with-maybeinvalid-t/24289#post_6",
  "publishedAt": "2026-05-11T22:55:19.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I've thought quite a lot about this, and I'm pretty sure that the correct model is along the lines of \"a data race for which the value read affects observable program behaviour is undefined behaviour\" but permitting, e.g., reading a value in a racy way but discarding it before making any use of it, as long as the read was done using a function specifically designed to permit races. (You can think of this as a \"data races read as LLVM's poison value\" sort of model, which clearly explains the \"both threads print 1\" example above as both threads would be printing poison.) This is sufficient for sequence locks because you can read the value, then check whether the read could have been raced against, and discard the read value without doing anythng with it if a race could have existed.\n\nLLVM effectively implements a version of this (by making raced reads return undef, which is strictly more defined than poison is), and for all reads rather than just specially marked ones.\n\nI tried (a while ago) to prove that any compiler that allowed separate compilation and opaque inline-asm blocks and that implemented the C++ memory model would also implement this memory model (in which case we could get an implementation of the memory model we wanted simply by using our existing compilers that follow the C++ memory model), via implementing the race-allowed read as an assembly-level read that was opaque to the compiler. Unfortunately, the result turned out to be false, but only in a fairly unlikely situation (in which the compiler uses the fact that a block of opaque code would race in one scenario in order to make assumptions about how it behaves in different scenarios). As such, I'm fairly confident that implementing a racy read using an inline asm that's opaque to the compiler would work in practice, despite there being a theoretical possibility of it breaking if LLVM adds an unlikely sort of optimisation.",
  "title": "Include racy reads in Rust memory model with `MaybeInvalid<T>`"
}