Stream: t-lang/wg-unsafe-code-guidelines

Topic: CppCon 2019: JF Bastien “Deprecating volatile”


Lokathor (Oct 21 2019 at 00:09, on Zulip):

To all the folks in UCG who have been working with where Volatile should go in Rust, here's a talk released yesterday about where Volatile has been and (for C++) where it might be going. Could be helpful for tackling volatile in Rust as well.
https://www.youtube.com/watch?v=KJW_DLaVXIY

RalfJ (Oct 21 2019 at 16:51, on Zulip):

thanks; I know they have some ongoing work there but it's good to get an update

RalfJ (Oct 21 2019 at 16:52, on Zulip):

last time I checked it wasnt very Rust-relevant; IIRC they were moving more towards volatile accesses as opposed to volatile objects which is what we already do anyway... or am I entirely misremembering?

Lokathor (Oct 21 2019 at 18:40, on Zulip):

Yeah we already do what they're trying to move towards in the next few years.

I'd say the biggest deal there is that volatile access can tear, and they don't plan to fix that for normal volatile, because the hardware itself doesn't even always give you that assurance.

RalfJ (Oct 21 2019 at 19:53, on Zulip):

yeah... though it still seems useful to guarantee that we dont tear the instruction. that lets the user reason on the hardware level.

RalfJ (Oct 21 2019 at 19:53, on Zulip):

it is somewhat disappointing that with their volatile load/store methods they are copying Rust's design but not citing it as prior work :/

Hadrien Grasland (Oct 21 2019 at 20:14, on Zulip):

Isn't Rust itself copying what LLVM does here ?

RalfJ (Oct 21 2019 at 20:20, on Zulip):

possible? not sure what the API was inspired from

RalfJ (Oct 21 2019 at 20:20, on Zulip):

however it does make a difference whether one designs an IR or a surface language

RalfJ (Oct 21 2019 at 20:21, on Zulip):

and Rust as a surface language has some experience now with volatile-access-methods, which is not something where having it in LLVM helps

Lokathor (Oct 22 2019 at 00:16, on Zulip):

yeah Rust and the C++ plan are both copying LLVM's notion of how things work.

gnzlbg (Oct 22 2019 at 12:02, on Zulip):

That talk is mostly C++ fixing C++-specific weirdness

gnzlbg (Oct 22 2019 at 12:03, on Zulip):

Once they do that, they might get to the point were the only weirdness remaining is the same one Rust needs to deal with

gnzlbg (Oct 22 2019 at 12:03, on Zulip):

but until then, they just have lower hanging fruit to fix

gnzlbg (Oct 22 2019 at 12:03, on Zulip):

they might be proposing moving to a model were volatile and atomics aren't types, but types of memory accesses instead

gnzlbg (Oct 22 2019 at 12:03, on Zulip):

apparently that's what the Linux kernel does

gnzlbg (Oct 22 2019 at 12:04, on Zulip):

also, they use the term atomic to mean, among other things "not tearing"

gnzlbg (Oct 22 2019 at 12:05, on Zulip):

(or maybe even "at least not tearing", whether all atomics will synchronize appears to be disputed but the talk does not go into it)

gnzlbg (Oct 22 2019 at 12:07, on Zulip):

An interesting example they show is the following:

static FOO: i32;
fn foo() {
    (&FOO as *const _).read_volatile();
}

they don't propose being able to optimize foo into fn foo() {} but they ask the question: "what does that do?"

gnzlbg (Oct 22 2019 at 12:08, on Zulip):

e.g. even if that does MMIO, is there a target where reading the memory has some interesting side-effects or can the read be elided ?

Lokathor (Oct 22 2019 at 16:30, on Zulip):

there's definitely targets where a read has a side effect of its own

Lokathor (Oct 22 2019 at 16:30, on Zulip):

the only one that comes to mind offhand is the NES, but i bet we could find others

Hadrien Grasland (Oct 22 2019 at 16:53, on Zulip):

On every platform that has an MMU, a read can cause a page fault, which in turn can have arbitrary software-defined side-effects.

Last update: Nov 19 2019 at 18:45UTC