以为我正在处理 ConfigureAwait
,然后我尝试了一个实验。
我的理解是 ConfigureAwait(false)
只有在有同步上下文的情况下才会有所作为。
ASP、WPF 等应该有上下文,但控制台应用程序和服务应用程序不应该。
为了了解它是如何工作的,我制作了一个 Web API 应用程序并包含了以下方法:
// GET api/values/5
public async Task<string> Get (int id)
{
var syncCtx = SynchronizationContext.Current;
int startThreadId = Thread.CurrentThread.ManagedThreadId;
await Task.Delay(TimeSpan.FromSeconds(3)).ConfigureAwait(true);
int endThreadId = Thread.CurrentThread.ManagedThreadId;
return "Start Thread ID: " + startThreadId.ToString() +
": End Thread ID: " + endThreadId.ToString();
}
我的预测是,在没有 ConfigureAwait
或 ConfigureAwait
设置为 true
的情况下,我应该在等待之前和之后看到相同的线程 ID。
我的前几次测试完全显示了上面的真实集。
无论 ConfigureAwait
是什么,代码的后续运行都在不同的线程 ID 上开始和结束。
我添加了 syncCtx
来说服自己我有上下文。
我读到的一个警告是,如果任务已完成,您将无法保证获得相同的 ID。这里是这样吗?如果是这样,为什么会这样?
我是否设置了天真或有缺陷的测试?如果是这样,什么是适当的测试?
我在控制台/服务应用程序中沿着这条路开始,并意识到我没有获得相同的线程 ID。我正在添加 ConfigureAwait(false)
,这是我所见过的大多数“最佳实践”文章中推荐的。因为我想看看事情到底是如何工作的,所以我尝试测试线程 ID。看到它们的不同,我进行了多次搜索,得出了上述代码。
最佳答案
执行 ConfigureAwait(true)
(或只是将其关闭,因为它是默认值)不会使其在同一线程上运行。它告诉 SynchronizationContext.Current
执行 Post
或 Send
与其余的继续。未定义 Post 或 Send 实际如何运行该代码。
WindowsFormsSynchronizationContext
和 DispatcherSynchronizationContext
(WinForms 和 WPF 的上下文)都将继续放入要由消息泵(UI 线程)处理的消息队列。
另一方面,AspNetSynchronizationContext
(这是您正在运行的环境)只是设置了一些状态信息(例如将 HttpContext.Current
设置回其旧值) ,然后它将工作排队到下一个可用的线程池线程。 ASP.NET 没有“消息泵”,它只是在线程池上完成所有工作,因此稍后尝试从线程池中取出同一个线程是没有意义的,该线程可能已经在继续发生时被销毁。
在continuation之前和之后你看到相同ID的次数你很幸运并且相同的线程被拉出线程池。
我强烈建议您阅读 MSDN 杂志文章“It's All About the SynchronizationContext”,它详细解释了 SynchronizationContext 的工作原理,并详细介绍了 .NET 中内置的 4 种上下文。
关于C# 任务 ConfigureAwait,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26308044/