A memory model for Rust code in the kernel
A memory model for Rust code in the kernel
Posted Apr 8, 2024 14:41 UTC (Mon) by foom (subscriber, #14868)In reply to: A memory model for Rust code in the kernel by marcH
Parent article: A memory model for Rust code in the kernel
But also, gcc and clang have supported it as a compiler built-in function since forever. The kernel has never been shy about using compiler extensions elsewhere, so I'm not sure why the inability to do atomic access on non-atomic-typed memory in standard C is even a point of discussion.
Such functionality is certainly useful for some rare cases, but does mean the user has to _manually_ deal with ensuring the alignment is as high as required, and ensure that the memory isn't accessed non-atomically at the same time as atomically (or else UB).
It's good for the functionality to exist, but it's also good for it not to be the default, because atomics already have enough sharp edges without. I'd note also that in most cases, it is entirely sufficient to drop down to a memory_order_relaxed access, instead of dropping to a non-atomic access. The cost of a relaxed atomic access is minimal, as are the guarantees (more sharp edges!).