intrusive_ptr_*(): specify memory_order explicitly #10297
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Al2Klimov
added
the
core/quality
|
I have unassigned myself from this PR because I don't think I can give good feedback here. However, could you please provide some deeper insights why this is a good idea? Perhaps some performance metrics? Generally speaking, "less safety guarantees" is something I would try to avoid at any cost. |
|
This is hard to measure, but we do those refcounts literally everywhere. IMAO a little more performance is better than no more performance. Sure, I explicitly said "less safety guarantees". But I meant less than right now, not less than std::shared_ptr. I mean, if THEY are fine with it... 🤷♂️ |
More relaxed memory_order = less safety guarantees = faster execution. This is safe because std::shared_ptr does the same. See also: https://en.cppreference.com/w/cpp/atomic/memory_order "Typical use for relaxed memory ordering is incrementing counters, such as the reference counters of std::shared_ptr, since this only requires atomicity, but not ordering or synchronization (note that decrementing the std::shared_ptr counters requires acquire-release synchronization with the destructor)."
Al2Klimov
force-pushed
the
intrusive_ptr_refcnt
branch
from
925a266 to
c8dccd9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
More relaxed memory_order = less safety guarantees = faster execution.
This is safe because std::shared_ptr does the same. See also: https://en.cppreference.com/w/cpp/atomic/memory_order "Typical use for relaxed memory ordering is incrementing counters, such as the reference counters of std::shared_ptr, since this only requires atomicity, but not ordering or synchronization (note that decrementing the std::shared_ptr counters requires acquire-release synchronization with the destructor)."