Move thread pool initialization to native side #36789
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
kouvel
commented
May 20, 2020
kouvel
commented
- Following up from Remove per enqueue volatile check in TheadPool #36697. Currently the initialization occurs when a static variable is accessed before calling into the VM, and after thinking about it some more the intent and need to initialize the thread pool can be a bit unclear
- The initialization is specific to this implementation and the managed side doesn't necessarily need to know about it
- Moved the initialization to the native side similarly to other thread pool APIs
- Added some more assertions to relevant managed-to-native entry point paths to ensure that they are not called before the thread pool is initialized
- This adds a non-volatile check when requesting a worker thread, which is already a very slow path. I ran into some issues with testing on the arm64 machine with updated locally built libcoreclr.so, so wasn't able to test that. I looked at the baseline profile and looking at time spent exclusively in ThreadPoolNative::RequestWorkerThread() and what it already does, I don't think the change would result in any significant perf difference.
- Following up from dotnet#36697. Currently the initialization occurs when a static variable is accessed before calling into the VM, and after thinking about it some more the intent and need to initialize the thread pool can be a bit unclear - The initialization is specific to this implementation and the managed side doesn't necessarily need to know about it - Moved the initialization to the native side similarly to other thread pool APIs - Added some more assertions to relevant managed-to-native entry point paths to ensure that they are not called before the thread pool is initialized - This adds a non-volatile check when requesting a worker thread, which is already a very slow path. I ran into some issues with testing on the arm64 machine with updated locally built libcoreclr.so, so wasn't able to test that. I looked at the baseline profile and looking at time spent exclusively in ThreadPoolNative::RequestWorkerThread() and what it already does, I don't think the change would result in any significant perf difference.
kouvel
requested review from
akoeplinger,
EgorBo,
marek-safar,
steveisok and
vargaz
as code owners
benaadams
approved these changes
May 20, 2020
src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPool.Portable.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Ben Adams <thundercat@illyriad.co.uk>
akoeplinger
approved these changes
May 25, 2020
stephentoub
approved these changes
May 26, 2020
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.