volatile [LWN.net]

volatile

Posted Oct 7, 2021 16:06 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624)
In reply to: volatile by tialaramex
Parent article: McKenney: So You Want to Rust the Linux Kernel?

DEC Alpha needs a full memory-barrier instruction after the load emitted by READ_ONCE().

Itanium needs a READ_ONCE() to emit an acquire-load instruction and a WRITE_ONCE() to emit a store-release instruction, but the C compiler takes care of that for us. Plus it is not obvious that Rust would ever need to care about this particular case.

ARMv8 needs a READ_ONCE() to emit an acquire-load instruction, but only in kernel builds that enable LTO, that is, builds that have CONFIG_LTO or similar enabled. (This choice stems from concerns that LTO breaks address, data, and/or control dependencies.)

So not massively complex, but something that needs to be kept track of.

to post comments

volatile

Posted Oct 8, 2021 19:24 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (1 responses)

So, if I'm not misunderstanding you need acquire-release semantics (you don't need to ask for them on x86 because x86 always has acquire-release semantics), that's what all of these cases seem to be doing.

Because x86 doesn't care, I don't actually know and it wouldn't surprise me if the existing volatile intrinsics already have acquire-release on every platform. But even if not it does still feel like this makes more sense as a (new) intrinsic than trying to call into C every time.

volatile

Posted Oct 8, 2021 20:09 UTC (Fri) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Why not take a look at the actual Rust documentation and implementation to see what the Rust volatile intrinsics actually guarantee across architectures?