异步/等待-是并发*吗? [英] Async/Await - is it *concurrent*?

问题描述

我一直在考虑C#5中的新异步内容，然后出现了一个特定问题.

I've been considering the new async stuff in C# 5, and one particular question came up.

我了解 await 关键字是实现继续传递，其中方法的其余部分分解为 Task 对象，并排队等待按顺序运行，但控制权返回给调用方法.

I understand that the await keyword is a neat compiler trick/syntactic sugar to implement continuation passing, where the remainder of the method is broken up into Task objects and queued-up to be run in order, but where control is returned to the calling method.

我的问题是，我听说目前所有这些都在一个线程上.这是否意味着异步的东西实际上只是将连续代码转换为 Task 对象，然后在每个任务完成之后调用 Application.DoEvents()，然后再开始下一个任务的方式?

My problem is that I've heard that currently this is all on a single thread. Does this mean that this async stuff is really just a way of turning continuation code into Task objects and then calling Application.DoEvents() after each task completes before starting the next one?

还是我错过了什么?(问题的这一部分是修辞性的-我完全知道我缺少了某些东西 :))

Or am I missing something? (This part of the question is rhetorical - I'm fully aware I'm missing something :) )

推荐答案

它是并发的，从某种意义上说，许多未完成的异步操作可能随时都在进行.它可能是多线程，也可能不是.

It is concurrent, in the sense that many outstanding asychronous operations may be in progress at any time. It may or may not be multithreaded.

默认情况下， await 将继续时间安排回当前执行上下文".如果当前执行上下文"不是非 null ，则定义为 SynchronizationContext.Current ；如果没有，则定义为 TaskScheduler.Current .SynchronizationContext .

By default, await will schedule the continuation back to the "current execution context". The "current execution context" is defined as SynchronizationContext.Current if it is non-null, or TaskScheduler.Current if there's no SynchronizationContext.

您可以通过调用 ConfigureAwait 并为 continueOnCapturedContext 参数传递 false 来覆盖此默认行为.在这种情况下，将不会将继续调度回该执行上下文.这通常意味着它将在线程池线程上运行.

You can override this default behavior by calling ConfigureAwait and passing false for the continueOnCapturedContext parameter. In that case, the continuation will not be scheduled back to that execution context. This usually means it will be run on a threadpool thread.

除非您正在编写库代码，否则默认行为正是您所期望的.WinForms，WPF和Silverlight(即所有UI框架)都提供了 SynchronizationContext ，因此该延续在UI线程上执行(并且可以安全地访问UI对象).ASP.NET还提供了 SynchronizationContext ，以确保继续操作在正确的请求上下文中执行.

Unless you're writing library code, the default behavior is exactly what's desired. WinForms, WPF, and Silverlight (i.e., all the UI frameworks) supply a SynchronizationContext, so the continuation executes on the UI thread (and can safely access UI objects). ASP.NET also supplies a SynchronizationContext that ensures the continuation executes in the correct request context.

其他线程(包括线程池线程， Thread 和 BackgroundWorker )不提供 SynchronizationContext .因此，默认情况下，控制台应用程序和Win32服务根本没有 SynchronizationContext .在这种情况下，继续在线程池线程上执行.这就是为什么使用 await / async 的控制台应用程序演示包含对 Console.ReadLine / ReadKey 的调用或执行在 Task 上阻止 Wait .

Other threads (including threadpool threads, Thread, and BackgroundWorker) do not supply a SynchronizationContext. So Console apps and Win32 services by default do not have a SynchronizationContext at all. In this situation, continuations execute on threadpool threads. This is why Console app demos using await/async include a call to Console.ReadLine/ReadKey or do a blocking Wait on a Task.

如果发现自己需要 SynchronizationContext ，则可以使用 AsyncContext 从我的 Nito.AsyncEx 库中；它基本上只是提供一个 async 兼容的主循环"和一个 SynchronizationContext .我发现它对控制台应用程序和单元测试很有用(VS2012现在内置了对 async Task 单元测试的内置支持).

If you find yourself needing a SynchronizationContext, you can use AsyncContext from my Nito.AsyncEx library; it basically just provides an async-compatible "main loop" with a SynchronizationContext. I find it useful for Console apps and unit tests (VS2012 now has built-in support for async Task unit tests).

有关 SynchronizationContext 的更多信息，请参见我2月的MSDN文章.

For more information about SynchronizationContext, see my Feb MSDN article.

任何时候都不会出现 DoEvents 或类似的名称；相反，控制流完全返回，计划继续执行(该功能的其余部分)稍后再执行.这是一个更干净的解决方案，因为它不会像使用 DoEvents 时那样会引起重入问题.

At no time is DoEvents or an equivalent called; rather, control flow returns all the way out, and the continuation (the rest of the function) is scheduled to be run later. This is a much cleaner solution because it doesn't cause reentrancy issues like you would have if DoEvents was used.

这篇关于异步/等待-是并发*吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！