Use reader/writer lock instead of mutex for ComWrappers RCW cache#91120
Use reader/writer lock instead of mutex for ComWrappers RCW cache#91120AaronRobinsonMSFT merged 1 commit intodotnet:mainfrom
ComWrappers RCW cache#91120Conversation
|
/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