异步/等待 - 是*并发*吗? [英] 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 会将继续安排回当前执行上下文".当前执行上下文"被定义为 SynchronizationContext.Current 如果它是非null，或者 TaskScheduler.Current 如果没有 同步上下文.

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 的更多信息，请参阅我在 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屋！