ConcurrentDictionary.Count bypass #11212
Open
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.
profiler was repeatedly complaining about ConcurrentDictionary.Count taking locks too often.
This PR introduces an approximate counter to remedy that
Context
ConcurrentDictionary.Count locks all its internal locks to have the count accurate and up to date.
However we only use the count to check if there is a reason to clean up the cache - e.g. we should be fine with a variable that is almost-in-sync with the .Count, that we can update atomically and then read without locking.
The increment is atomic, the read is accurate enough and the "flush cache" section is already behind a lock.
Changes Made
Introduced _count variable that lists the same value as ConcurrentDictionary.Count would.
Testing
Now that I looked at this, we didn't have a test for the scavenge threshold. We only ever tested the .scavenge directly.
Do we want to remedy that or are we fine as is?