volatile and sensitive memory

[nikomatsakis]

This issue is a placeholder for the topic brought up by @briansmith on a previous internals thread:

In Rust, there is no volatile modifier. Instead, there are unstable “volatile read” and “volatile write” primitives. And, it seems like those will be stabilized soon. So, since there is no volatile modifier, does that mean that the Rust compiler must assume that all memory is volatile by default? In particular, in general given x: &u64, the compiler won't know if x is a reference to value stored in volatile memory, right? Thus, it will never be able to do speculative reads of x and in general it must make sure it uses ACCESS_ONCE style access to every such value, unless it can prove that x is not a reference to volatile memory, which is in general very hard. Is that right?

It seems like it can't be right, because this seems like it would be horrible for performance. But, I can't figure out how the proposed “volatile read” and “volatile write” functions work otherwise. In particular, “volatile read” and “volatile write” seem to only make sense under the assumption that there are no speculative reads/writes to the memory they are writing to, but there's no way to indicate to rustc that no speculative reads/writes are allowed.

The (tentative) conclusion of this thread was as follows:

For the time being, we have de facto adopted LLVM's "volatile access model". Personally, I am pretty comfortable with this, and I would not expect major changes. This implies to me that @huon's example of a volatile wrapper is currently correct (as @huon points out, the VolatileCell example is not, though for a reason that is orthogonal to volatility).

The key point is that the compiler will not randomly introduce reads of an &T -- it will only introduce reads that it can prove may happen at some point in the future. This is (I believe) true even with the derefenceable attribute. So if you have a field x: T and it is only ever read via a volatile-read, then the compiler will not introduce spurious, non-volatile reads of it. I believe this is the LLVM's (and hence Rust's) current semantics (@briansmith seems to have come to the same conclusion).

[gnzlbg]

volatile unaligned loads and stores (unaligned_volatile_{load,store}) are now available in nightly (rust-lang/rust#52391), so we'd have to consider their interaction with the memory model as well.

[RalfJung]

Closing in favor of rust-lang/unsafe-code-guidelines#33.