Uh oh!
There was an error while loading. Please reload this page.
Use reader/writer lock instead of mutex for ComWrappers RCW cache - #91120
Conversation
/cc @jkotas @dotnet/interop-contrib @manodasanW |
jkotas
commented
Aug 25, 2023
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. |
AaronRobinsonMSFT
commented
Aug 25, 2023
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 |
manodasanW
commented
Aug 25, 2023
For AOT, thoughts on the lock here for rcwCache. |
AaronRobinsonMSFT
commented
Aug 25, 2023
I was misinformed. Sad. Okay, that needs to change. |
AaronRobinsonMSFT
commented
Aug 25, 2023
@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. |
AaronRobinsonMSFT
commented
Aug 25, 2023
NAOT
CoreCLR
|
AaronRobinsonMSFT
commented
Aug 25, 2023
Benchmark PR - dotnet/performance#3298 |
AaronRobinsonMSFT
commented
Aug 25, 2023
/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