Fix thread-safety of FixedCapacityExponentialHistogram.valueCount#137357
Merged
JonasKunz merged 2 commits intoelastic:mainfrom Oct 30, 2025
Merged
Fix thread-safety of FixedCapacityExponentialHistogram.valueCount#137357JonasKunz merged 2 commits intoelastic:mainfrom
JonasKunz merged 2 commits intoelastic:mainfrom
Conversation
elasticsearchmachine
added
needs:triage
JonasKunz
added
>non-issue
:StorageEngine/Mapping
Collaborator
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
felixbarny
approved these changes
Oct 30, 2025
|
|
||
| private record CachedCountsSum(int numBuckets, long countsSum) {} | ||
|
|
||
| private CachedCountsSum cachedCountsSum; |
Member
There was a problem hiding this comment.
Just thinking out loud: this could be volatile or an AtomicReference so that other threads can see the cached value. But this doesn't affect correctness as the worst thing that could happen is that another thread needs to re-compute the value. That's probably not something we're trying to optimize for.
Contributor
Author
There was a problem hiding this comment.
Yes that was my though here too: AtomicReference would be the same as volatile here, as we don't do CAS.
However, we don't want to "pay" for volatile here, as it's okay if threads see the cached value too late, because then they will just compute it themselves.
nik9000
reviewed
Oct 30, 2025
|
|
||
| private record CachedCountsSum(int numBuckets, long countsSum) {} | ||
|
|
||
| private CachedCountsSum cachedCountsSum; |
| * This works around that by running it once up front. Jonas will have a | ||
| * look at this one soon. | ||
| */ | ||
| histo.hashCode(); |
chrisparrinello
pushed a commit
to chrisparrinello/elasticsearch
that referenced
this pull request
Nov 3, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
Follow up for #137350, fixes the actual root cause and removes the workaround.
The
FixedCapacityExponentialHistogramis mutable to allow for an efficient construction and reuse within the exponential histogram lib. However, the class is private to the library, meaning that it can only be accessed via theExponentialHistograminterface from outside of the library.The
ExponentialHistograminterface does not allow for mutations, thereforeFixedCapacityExponentialHistogramwhen viewed (and exclusively owned) this way should be thread safe.Prior to this PR this was not the case: We lazily compute the sum of the counts for buckets and cache it as needed.
To make this as efficient as possible, e.g. even after adding more buckets to the histogram, we remember for how many buckets we cached the sum and only add new ones on top.
Calling
valueCount()would mutate and read the relevant members in a loop, leading to a race condition.This PR (a) reproduces the problem in a test and (b) fixes it by replacing the racy member accesses with single reference load and store, which are therefore atomic.