在 blog post 中, Microsoft 的 Sergey Tepliakov 说:
you should always provide TaskCreationOptions.RunContinuationsAsynchronously when creating TaskCompletionSource instances.
但在那篇文章中,除非我误解了,他还说所有 await
延续基本上与没有 TaskCreationOptions 的
。所以这意味着 TaskCompletionSource
一样.RunContinuationsAsynchronouslyasync
和 await
本质上也是危险的,不应该使用,除非 await Task.Yield()
被用作好吧。罢工>
(编辑:我确实误解了它。他说 await
同步继续是有问题的 SetResult
行为的原因。如果无法在源头控制任务创建,建议将 await Task.Yield()
作为客户端解决方法。除非我又误解了什么。)
我得出的结论是,一定存在使同步延续变得危险的特定情况,显然这些情况对于 TaskCompletionSource
用例来说很常见。那些危险的情况是什么?
最佳答案
线程窃取,基本上。
这里的一个很好的例子是一个客户端库,它通过网络与某个服务器进行对话,该服务器被实现为同一连接上的一系列帧(例如,http/2 或 RESP)。无论出于何种原因,假设每次调用库都会返回一个 Task<T>
。 (对于某些 <T>
)已由 TaskCompletionSource<T>
提供正在等待网络服务器的结果。
现在您要编写从服务器(可能来自套接字、流或管道 API)出列响应的读取循环,解析相应的 TaskCompletionSource<T>
(这可能意味着“队列中的下一个”,或者可能意味着“使用响应中存在的唯一相关 key / token ”)。
所以你实际上有:
while (communicationIsAlive)
{
var result = await ParseNextResultAsync(); // next message from the server
TaskCompletionSource<Foo> tcs = TryResolveCorrespondingPendingRequest(result);
tcs?.TrySetResult(result); // or possibly TrySetException, etc
}
现在;假设您没有使用 RunContinuationsAsynchronously
当你创建 TaskCompletionSource<T>
.你做的那一刻TrySetResult
,继续执行当前线程。这意味着 await
在某些任意客户端代码(可以执行任何操作)中,现在已经中断了您的 IO 读取循环,并且不会处理其他结果,直到该线程放弃该线程。
使用 RunContinuationsAsynchronously
允许您使用 TrySetResult
(等)而不必担心您的线程被盗。
(更糟糕的是:如果将其与对同一资源的后续异步同步调用结合使用,可能会导致硬死锁)
此标志存在之前的相关问题:How can I prevent synchronous continuations on a Task? .
关于c# - 同步延续到底什么时候是危险的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/64241051/