This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Force secondary await continuations to run asynchronously #25280
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
For performance reasons, await continuations have been invoked synchronously, meaning they're invoked as part of the antecedent task's completion (as long as that task allows it, as long as there's sufficient stack space, etc.) This generally works out well in the case where there's a single await continuation, which is far and away the common case. However, it can cause problems in situations where there are multiple await continuations, as those continuations will end up being serialized, which can lead to slowdowns and deadlocks in niche situations. To address that, this commit backs off a bit. The first await continuation is still invoked synchronously, but subsequent await continuations are invoked asynchronously, such that they are not blocked by a previously registered await continuation.
|
We have hit similar cases as described in dotnet/corefx#34781 so I'm super stoked to see this fixed! |
tarekgh
reviewed
Jun 20, 2019
tarekgh
reviewed
Jun 20, 2019
src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs
Outdated
Show resolved
Hide resolved
AArnott
approved these changes
Jun 20, 2019
src/System.Private.CoreLib/shared/System/Threading/Tasks/Task.cs
Outdated
Show resolved
Hide resolved
tarekgh
approved these changes
Jun 20, 2019
kouvel
approved these changes
Jun 20, 2019
Yes, in corefx. |
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
…eclr#25280) * Force secondary await continuations to run asynchronously For performance reasons, await continuations have been invoked synchronously, meaning they're invoked as part of the antecedent task's completion (as long as that task allows it, as long as there's sufficient stack space, etc.) This generally works out well in the case where there's a single await continuation, which is far and away the common case. However, it can cause problems in situations where there are multiple await continuations, as those continuations will end up being serialized, which can lead to slowdowns and deadlocks in niche situations. To address that, this commit backs off a bit. The first await continuation is still invoked synchronously, but subsequent await continuations are invoked asynchronously, such that they are not blocked by a previously registered await continuation. * Fix nits Commit migrated from dotnet/coreclr@d58a283
8 tasks
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.
For performance reasons, await continuations have been invoked synchronously, meaning they're invoked as part of the antecedent task's completion (as long as that task allows it, as long as there's sufficient stack space, etc.) This generally works out well in the case where there's a single await continuation, which is far and away the common case. However, it can cause problems in situations where there are multiple await continuations, as those continuations will end up being serialized, which can lead to slowdowns and deadlocks in niche situations. To address that, this commit backs off a bit. The first await continuation is still invoked synchronously, but subsequent await continuations are invoked asynchronously, such that they are not blocked by a previously registered await continuation.
Fixes https://github.com/dotnet/corefx/issues/34781
cc: @tarekgh, @kouvel, @benaadams, @AArnott