Fix a documentation bug for memory orderings #27379
Conversation
As described in the module documentation, the memory orderings in Rust are the same with that of LLVM. However, the documentation for the memory orderings enum says the memory orderings are the same of that of C++. Note that they differ in that C++'s support the consume reads, while LLVM's does not. Hence this commit fixes the bug in the documentation for the enum.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pcwalton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
@bors: r+ rollup |
|
📌 Commit 2081aa6 has been approved by |
|
Thanks! |
As described in the module documentation, the memory orderings in Rust are the same with that of LLVM. However, the documentation for the memory orderings enum says the memory orderings are the same of that of C++. Note that they differ in that C++'s support the consume reads, while LLVM's does not. Hence this commit fixes the bug in the documentation for the enum.
|
We actually explicitly intend C's memory model just "without consume", which doesn't really change the semantics or anything. Arguably we should be linking to the C standard's memory model |
|
@gankro I agree with Rust community's choice to ignore consume loads at the current moment, which LLVM also takes, in that the semantics of consume loads are not well established yet. There is an ongoing discussion in both the Standard committee and the academia. (Even, release/acquire semantics is subject to discussion in programming languages and computer architecture disciplines.) But one thing I would like to argue is: consume loads "meant" something to compilers. GCC "tried" to understand the consume semantics and exploit it further than just the acquire semantics. But a bug was found in exploitation of the consume semantics, and they reverted to regard consume as just acquire, though. I believe some day the consume semantics will be settled, and compilers will rely on the semantics... If that dream comes true some day, maybe it would be possible that LLVM will incorporate the consume semantics, and so as Rust. But till then, our best shot will be just ignoring the consume loads. By the way, I found the discrepancy of the documentation in course of implementing in Rust a user-level RCU, which was the main motivation for the consume loads at the first moment. |
As described in the module documentation, the memory orderings in Rust
are the same with that of LLVM. However, the documentation for the
memory orderings enum says the memory orderings are the same of that of
C++. Note that they differ in that C++'s support the consume reads,
while LLVM's does not. Hence this commit fixes the bug in the
documentation for the enum.