-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Revert "Use a ReaderWriterLockSlim in RcwCache" #120370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This reverts commit a074813.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR reverts a previous change that introduced ReaderWriterLockSlim in the RcwCache class, replacing it back with the standard Lock implementation due to a functional regression. The change restores the simpler locking mechanism to address reported issues with the ReaderWriterLockSlim implementation.
Key changes:
- Reverts ReaderWriterLockSlim back to Lock with trivial waits optimization
- Simplifies locking code by removing explicit try-finally blocks and using lock statements
- Affects three methods: GetOrAddProxyForComInstance, FindProxyForComInstance, and Remove
Can we use an upgradable read lock (that upgrades to a write lock around the If we can avoid the perf regression from getting rid of the rwlock, I'd prefer that over taking the perf regression (for .NET 11 at least). |
@jkoritzinsky Based on my comment at #117775 (comment), I don't think this fixed the regression either. At this point, I'm not sure we can address the regression in .NET 10 GA. We need to circle back and verify the actual regression though. The RPS system doesn't seem to be tracking the continued regression in this space. |
I could have sworn this fixed the regression when I ran the benchmark locally and in my PR. Since it didn't, yeah let's revert and revisit. |
/backport to release/10.0 |
Started backporting to release/10.0: https://github.com/dotnet/runtime/actions/runs/18230714561 |
{ | ||
_lock.EnterReadLock(); | ||
try | ||
lock (_lock) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here a readlock is not enough. It updates the hashtable under some circumstances, which may go concurrent under a read lock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upgrading to a write lock before the update (_cache.Remove()
) may help too... But the single lock is probably just as easy.
Reverts #117792
This introduced a functional regression reported in #120347.
Reopened #117775 performance regression issue introduced in #113907.
Fixes #119986
Fixes #120347