This repository was archived by the owner on Nov 1, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 1, 2020. It is now read-only.
Port normalized equivalent of YieldProcessor from CoreCLR #4430
Description
- Port Add normalized equivalent of YieldProcessor, retune some spin loops coreclr#13670
- Port any other PRs that fix relevant issues referenced in https://github.com/dotnet/coreclr/issues/13388
Activity
kouvel commentedon Jun 1, 2018
Nice to have, but it is not clear that it would have any significant impact, not likely to happen until a significant issue is shown to substantiate the work
kouvel commentedon Jan 12, 2019
Monitor still does a lot of spinning and porting the CoreCLR's implementation would probably benefit most
Suchiman commentedon Jul 3, 2019
@MichalStrehovsky is this fixed?
MichalStrehovsky commentedon Jul 3, 2019
This is in reference to #7569 (for the future me, since I failed to call this issue out in the pull request).
I left this open because I'm not sure how important it would be to migrate off of
YieldProcessorNormalizedForPreSkylakeCountto the new scheme withYieldProcessorNormalizationInfo.E.g. we're not exposing the
OptimalMaxSpinWaitsPerSpinIterationonSystem.Threading.Threadbut instead normalize the spin number passed toRhSpinWait. That's not what CoreCLR does and I wasn't sure how much that matters.@kouvel would know but he's out right now and this is going to get lost in his mailbox.
kouvel commentedon Aug 19, 2019
Switching off of the pre-Skylake spin scheme may also require retuning spin-waits with large spin counts. Where applicable, perhaps that could be done one component at a time in the future along with porting the spin scheme for the component from coreclr. I don't think it's critical though.
Unify Thread.SpinWait/Yield/OptimalMaxSpinWaitsPerSpinIteration betwe…