Read_once(), Write_once(), but Not for Rust
1–10 of 41 posts
Re: Read_once(), Write_once(), but Not for Rust
#2Very interesting. AFAIK the kernel explicitly gives consume semantics to read_once (and in fact it is not just a compiler barrier on alpha), so technically lowering it to a relaxed operation is wrong.
Does rust have or need the equivalent of std::memory_order_consume? Famously this was deemed unimplementable in C++.
Re: Read_once(), Write_once(), but Not for Rust
#3> The truth of the matter, though, is that the Rust community seems to want to take a different approach to concurrent data access.
Not knowing anything about development of the kernel, does this kind of thing create a two tier Linux development experience?
Re: Read_once(), Write_once(), but Not for Rust
#4Very interesting. AFAIK the kernel explicitly gives consume semantics to read_once (and in fact it is not just a compiler barrier on alpha), so technically lowering it to a relaxed operation is wrong. Does rust have or need the equivalent of std::memory_order_consume? Famously this was deemed unimplementable in C++.
It wasn’t implemented for the same reason. Rust uses C++20 ordering.
Re: Read_once(), Write_once(), but Not for Rust
#5> The truth of the matter, though, is that the Rust community seems to want to take a different approach to concurrent data access. Not knowing anything about development of the kernel, does this kind of thing create a two tier Linux development experience?
Not sure if it introduces a tiered experience or not. But reading the article it appears that the Rust devs advocated for an api that is clearer in it's semantics with the tradeoff that now understanding how it interacts with C code requires understanding two APIs. How this shakes out in practice remains to be seen.
Re: Read_once(), Write_once(), but Not for Rust
#6Very interesting. AFAIK the kernel explicitly gives consume semantics to read_once (and in fact it is not just a compiler barrier on alpha), so technically lowering it to a relaxed operation is wrong. Does rust have or need the equivalent of std::memory_order_consume? Famously this was deemed unimplementable in C++.
It wasn’t implemented for the same reason. Rust uses C++20 ordering.
right, so I would expect that the equivalent of READ_ONCE is converted to an acquire in rust, even if slightly pessimal.
But the article says that the suggestion is to convert them to relaxed loads. Is the expectation to YOLO it and hope that the compiler doesn't break control and data dependencies?
Re: Read_once(), Write_once(), but Not for Rust
#7Earlier quoted context omitted.
It wasn’t implemented for the same reason. Rust uses C++20 ordering.
right, so I would expect that the equivalent of READ_ONCE is converted to an acquire in rust, even if slightly pessimal. But the article says that the suggestion is to convert them to relaxed loads. Is the expectation to YOLO it and hope that the compiler doesn't break control and data dependencies?
There is a yolo way that actually works, which would be to change it to a relaxed load followed by an acquire signal fence.
Re: Read_once(), Write_once(), but Not for Rust
#8Earlier quoted context omitted.
right, so I would expect that the equivalent of READ_ONCE is converted to an acquire in rust, even if slightly pessimal. But the article says that the suggestion is to convert them to relaxed loads. Is the expectation to YOLO it and hope that the compiler doesn't break control and data dependencies?
There is a yolo way that actually works, which would be to change it to a relaxed load followed by an acquire signal fence.
Is that any better than just using an acquire load?
Re: Read_once(), Write_once(), but Not for Rust
#9Very interesting. AFAIK the kernel explicitly gives consume semantics to read_once (and in fact it is not just a compiler barrier on alpha), so technically lowering it to a relaxed operation is wrong. Does rust have or need the equivalent of std::memory_order_consume? Famously this was deemed unimplementable in C++.
Does anything care about Alpha? The platform hasn't been sold in 20 years.
Re: Read_once(), Write_once(), but Not for Rust
#10What is your take on their names instead of "atomic_read" and "atomic_write"?