Re:Rust: A Unique Perspective
by anonymousDan on Friday February 10, 2023 @05:59AM
(#34738103)
Does Rust provide support for low level synchronisation related operations such as memory fences? If so is there any way relying on these can break data race freedom (which as I understand Rust guarantees)?
[ Parent
| on HN ]
Re:Rust: A Unique Perspective
by shinazueli on Friday February 10, 2023 @06:08AM
(#34738173)
It has Atomics that use the same memory constraint model (Relaxed, SeqCst, etc), if that’s what you meant.
You can indeed create data races with them, but only in combination with unsafe code.
Re:Rust: A Unique Perspective
by anonymousDan on Friday February 10, 2023 @06:15AM
(#34738219)
I meant inserting barriers (read fence/write fence etc) explicitly. Thanks for the link, very interesting.
Re:Rust: A Unique Perspective
by jamesmunns on Friday February 10, 2023 @07:34AM
(#34738839)
Yep, we have `fence` for runtime+compile time barriers, and `compiler_fence` for compile time barriers. They take the same Ordering enum as atomics.
> If so is there any way relying on these can break data race freedom (which as I understand Rust guarantees)?
It’s not clear what your question is.
You can use unsafe to write unsound code which suffers from data races.
If you use safe Rust, then you should not suffer from data races (and fences only add constraints, so they can’t add data races, they’re tools to avoid those), although bugs are always possible and sometimes purportedly safe stdlib APIs are found to be unsound (that’s one of the few things for which the rust project allows breaking backwards compatibility, though even that depends on the blast radius e.g. std::mem::uninitialized is still there, just deprecated, even though there’s almost no way to use it soundly).