Open Imberflur opened 1 year ago
This does look reasonable to me, yeah! Although, as usual, I am unnerved by the fact that we don't have any tools to check this (or maybe I am missing them?).
Could you send a PR? You can also adjust the Changelog and bump the patch version in Cargo.toml, so that we release this together with #219
Note that CAS failure ordering that is stronger than success ordering requires Rust 1.64+: https://github.com/rust-lang/rust/pull/98383
Note that CAS failure ordering that is stronger than success ordering requires Rust 1.64+: https://github.com/rust-lang/rust/pull/98383
Gah! :slightly_frowning_face:
Although, as usual, I am unnerved by the fact that we don't have any tools to check this (or maybe I am missing them?).
The only thing that comes to my mind is testing with loom. I don't know if it is exactly what you are looking for though.
For example, the compare exchange for
OnceNonZeroUsize
usesAcqRel
for the success case: https://github.com/matklad/once_cell/blob/d706539c6f7cd47d0e8037d832c0c95214fb5f91/src/race.rs#L100The
Acquire
portion of theAcqRel
here is for the load of0
, however there is noRelease
store of0
so this will not synchronize with anything. Note that the construction ofOnceNonZeroUsize
still has a happens-before relationship to this since we have an&self
reference. Thus, I think aRelease
ordering is sufficient here for the desired synchronization to be achieved (including taking this documentation into account):I believe this applies to all uses of
compare_exchange
in this module.(happy to make a PR if this looks reasonable)