-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Use reader/writer lock instead of mutex for ComWrappers
RCW cache
#91120
Use reader/writer lock instead of mutex for ComWrappers
RCW cache
#91120
Conversation
/cc @jkotas @dotnet/interop-contrib @manodasanW |
Would it be possible to extract a repro into a microbenchmark in https://github.com/dotnet/performance? Also, it would be good to check how native AOT does on this microbenchmark. |
I will need to construct one. The repro was using C#/WinRT and would be non-trivial to recreate. I will see what I can do.
The data structure being used in AOT is the |
For AOT, thoughts on the lock here for rcwCache. |
I was misinformed. Sad. Okay, that needs to change. |
@jkotas and @manodasanW I'm genuinely shocked at this, but converting NAOT to use a reader/writer lock makes NAOT slower for a microbenchmark. I was able to see the expected speed in the microbenchmark with CoreCLR and the reader/writer lock so it is capturing the scenario, but there is nothing to do here for NAOT. I will work on pushing the benchmark into https://github.com/dotnet/performance. |
NAOT
CoreCLR
|
Benchmark PR - dotnet/performance#3298 |
/backport to release/8.0 |
Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5981298027 |
Switching to a reader/writer lock improves throughput for faster RCW look up by 4x. This was observed in a private repro associated with #90964.
Fixes #90964