HN

Need help?
<- Back
Read_once(), Write_once(), but Not for Rust

Read_once(), Write_once(), but Not for Rust

todsacerdoti

Comments (34)

  • bheadmaster
    An understanding of READ_ONCE() and WRITE_ONCE() is important for kernel developers who will be dealing with any sort of concurrent access to data. So, naturally, they are almost entirely absent from the kernel's documentation. Made me chuckle.
  • staticassertion
    > There are a couple of interesting implications from this outcome, should it hold. The first of those is that, as Rust code reaches more deeply into the core kernel, its code for concurrent access to shared data will look significantly different from the equivalent C code, even though the code on both sides may be working with the same data. Understanding lockless data access is challenging enough when dealing with one API; developers may now have to understand two APIs, which will not make the task easier.The thing is, it'll be far less challenging for the Rust code, which will actually define the ordering semantics explicitly. That's the point of rejecting the READ_ONCE/WRITE_ONCE approach - it's unclear what the goal is when using those, what guarantee you actually want.I suspect that if Rust continues forward with this approach it will basically end up as the code where someone goes to read the actual semantics to determine what the C code should do.
  • gpderetta
    Very 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++.
  • anon
    undefined
  • chrismsimpson
    > 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?
  • alilleybrinker
    In situations like this I appreciate that Rust has a culture of semantic precision [1] and while this kind of API-clarification is painful in the short-term, I think it will be worth it for Linux.[1]: https://www.alilleybrinker.com/mini/rusts-culture-of-semanti...
  • epolanski
    What is your take on their names instead of "atomic_read" and "atomic_write"?