about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/ArchiveWrapper.cpp
diff options
context:
space:
mode:
authorJacob Pratt <jacob@jhpratt.dev>2024-03-20 20:29:44 -0400
committerGitHub <noreply@github.com>2024-03-20 20:29:44 -0400
commit43ad753adbebf843ebdc3d0d82e991a329a599bd (patch)
tree3800a2a17a976b4afc2660fc1be7107e88de7ced /compiler/rustc_llvm/llvm-wrapper/ArchiveWrapper.cpp
parent31adfd77d265b12b0ebc30101d816e8a99948988 (diff)
parent34621757ea9437994ef717ac4f1928933a6e1b24 (diff)
downloadrust-43ad753adbebf843ebdc3d0d82e991a329a599bd.tar.gz
rust-43ad753adbebf843ebdc3d0d82e991a329a599bd.zip
Rollup merge of #122729 - m-ou-se:relax, r=Amanieu
Relax SeqCst ordering in standard library.

Every single SeqCst in the standard library is unnecessary. In all cases, Relaxed or Release+Acquire was sufficient.

As I [wrote](https://marabos.nl/atomics/memory-ordering.html#common-misconceptions) in my book on atomics:

> [..] when reading code, SeqCst basically tells the reader: "this operation depends on the total order of every single SeqCst operation in the program," which is an incredibly far-reaching claim. The same code would likely be easier to review and verify if it used weaker memory ordering instead, if possible. For example, Release effectively tells the reader: "this relates to an acquire operation on the same variable," which involves far fewer considerations when forming an understanding of the code.
>
> It is advisable to see SeqCst as a warning sign. Seeing it in the wild often means that either something complicated is going on, or simply that the author did not take the time to analyze their memory ordering related assumptions, both of which are reasons for extra scrutiny.

r? ````@Amanieu```` ````@joboet````
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/ArchiveWrapper.cpp')
0 files changed, 0 insertions, 0 deletions