c# - 同步延续到底什么时候是危险的?

标签 c# .net asynchronous .net-core async-await

blog post 中, Microsoft 的 Sergey Tepliakov 说:

you should always provide TaskCreationOptions.RunContinuationsAsynchronously when creating TaskCompletionSource instances.

但在那篇文章中,除非我误解了,他还说所有 await 延续基本上与没有 TaskCreationOptions 的 TaskCompletionSource 一样.RunContinuationsAsynchronously。所以这意味着 asyncawait 本质上也是危险的,不应该使用,除非 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/

相关文章:

.net - 如何避免 "vertically partitioned"程序集中的命名空间和类名冲突?

ios - swift 中的闭包正在做任何事情。我的代码执行不正常

c# - 如何在 XAML 中使默认属性不同于内容?

c# - 为什么我们在 GridView 中使用 Boundfield

c# - 如何通过 POST 将参数传递到 Azure Functions 2

c# - 检测 Excel 文件是否已关闭

c# - 如何在负载平衡环境中获取 DNS 名称?

c# - 具有类型参数的继承泛型类的协变是子类

javascript - 等待异步函数

c# - 为什么未等待的异步方法不抛出异常?