[hist] Ensure consistency of RBinWithError::AtomicAdd
#21105
+230
−13
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
Only have a single (private) function that invokes lower-level atomic operations on the two members fSum and fSum2.
Instead of using separate atomic operations on the two members, use the sign bit of fSum2 to implement a cheap spin lock. This allows another thread to detect inconsistent reads and implement a retry loop. According to the microbenchmarks, this is even faster with a single thread / for the uncontended case. A possible explanation is that the code needs only one compare-exchange operation instead of two. With multiple threads and heavy contention, the implementation is slightly slower. An alternative would be double-width compare-and-swap instructions, as found on x86 (cmpxchg16b). Setting aside the portability issues, GCC generates a library call to __atomic_compare_exchange_16 which is slower than two separate compare-exchange instructions. If a direct instruction is emitted (for example with Clang), it beats the separate compare-exchange instructions in the uncontended scenario and is tied in case of contention.
pcanal
reviewed
Feb 2, 2026
|
|
||
| void AtomicInc() | ||
| private: | ||
| void AtomicAdd(double a, double a2) |
Member
There was a problem hiding this comment.
Suggested change
| void AtomicAdd(double a, double a2) | |
| void SumAtomicAdd(double a, double a2) |
As this is specifically to atomic at the sum/sum2.
or
Suggested change
| void AtomicAdd(double a, double a2) | |
| void AtomicAddToSum(double a, double a2) |
Member
Author
There was a problem hiding this comment.
I think I would prefer to keep the current naming scheme: User-facing functions, such as FillAtomic, are implemented in terms of increasingly lower-level functions AtomicAdd. Given that it's a private function that is used to implemented other AtomicAdd functions just below, I think the current name is sufficient.
Test Results 22 files 22 suites 3d 12h 49m 9s ⏱️ Results for commit f639911. |
hageboeck
reviewed
Feb 4, 2026
Member
hageboeck
left a comment
hageboeck
left a comment
There was a problem hiding this comment.
LGTM in general, but for the future, should one think about preventing undesired modifications of the read-only arguments?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Instead of using separate atomic operations on the two members, use the sign bit of
fSum2to implement a cheap spin lock. This allows another thread to detect inconsistent reads and implement a retry loop.According to the microbenchmarks, this is even faster with a single thread / for the uncontended case. A possible explanation is that the code needs only one compare-exchange operation instead of two. With multiple threads and heavy contention, the implementation is slightly slower.
An alternative would be double-width compare-and-swap instructions, as found on x86 (
cmpxchg16b). Setting aside the portability issues, GCC generates a library call to__atomic_compare_exchange_16which is slower than two separate compare-exchange instructions. If a direct instruction is emitted (for example with Clang), it beats the separate compare-exchange instructions in the uncontended scenario and is tied in case of contention.