如何不同的异步编程为主题？ [英] How different async programming is from Threads?

问题描述

我一直在阅读一些异步文章在这里：<一href=\"http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45\">http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45和笔者说：

I've been reading some async articles here: http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 and the author says :

当你正在做异步工作方式，你并不总是使用一个线程。
  例如，当你做出一个异步Web服务请求，
  ASP.NET将不使用异步方法调用之间的线程
  和游览车。

When you’re doing asynchronous work, you’re not always using a thread. For example, when you make an asynchronous web service request, ASP.NET will not be using any threads between the async method call and the await.

那么，我想明白的是，它是如何成为异步如果我们不使用并行执行的线程？这是什么意思你不是一直使用一个线程。

So what I am trying to understand is, how does it become async if we don't use any Threads for concurrent execution? What does it mean "you're not always using a thread."?

让我先解释一下我所知道的关于与线程（一个简单的例子，当然线程可以在这里比的用户界面和工人的方法不同的情况下使用）

Let me first explain what I know regarding working with threads (A quick example, of course Threads can be used in different situations other than UI and Worker methodology here)

1. 您有UI线程采取输入，输出给


2. 您可以处理的事情在UI线程，但它使UI响应。


3. 因此，可以说，我们有一个流相关的操作，我们需要下载某些类型的数据。


4. 我们也允许而被下载了它的用户做其他的事情。


5. 我们创建一个新的工作线程会下载该文件，并改变了进度条。


6. 一旦做了，没有什么可以做的线程被杀害。


7. 我们继续从UI线程。

我们可以等待根据不同的情况，但在此之前，当文件被下载，我们可以做其他事情与UI线程，然后等待工作线程。

We can either wait for the worker thread in UI thread depending on the situation but before that while the file is being downloaded, we can do other things with UI thread and then wait for the worker thread.

不是同异步编程？如果不是，有什么区别？我读异步编程使用线程池从拉虽然线程。

Isn't the same for async programming? If not, what's the difference? I read that async programming uses ThreadPool to pull threads from though.

推荐答案

线程是没有必要的异步编程。

Threads are not necessary for asynchronous programming.

异步表示API不会阻止的呼叫的线程。它的不的意思是存在着的另一个线程的阻塞。

"Asynchronous" means that the API doesn't block the calling thread. It does not mean that there is another thread that is blocking.

首先，用实际的异步API的考虑你的UI的例子，这一次：

First, consider your UI example, this time using actual asynchronous APIs:

1. 您有UI线程采取输入，输出给


2. 您可以处理的事情在UI线程，但它使UI响应。


3. 因此，可以说，我们有一个流相关的操作，我们需要下载某些类型的数据。


4. 我们也允许而被下载了它的用户做其他的事情。


5. 我们使用异步API来下载该文件。否工作线程是必要的。


6. 异步操作报告其进度回UI线程（其更新进度条），而且它也报告其完成到UI线程（其可以像任何其他事件进行​​响应）。

1. You have UI Thread to take input, give output.
2. You can handle things in UI Thread but it makes the UI unresponsive.
3. So lets say we have a stream-related operation and we need to download some sort of data.
4. And we also allow users to do other things while it is being downloaded.
5. We use asynchronous APIs to download the file. No worker thread is necessary.
6. The asynchronous operation reports its progress back to the UI thread (which updates the progress bar), and it also reports its completion to the UI thread (which can respond to it like any other event).

这显示了如何只能有一名参与线程（UI线程），但也有异步操作回事。您可以启动多个异步操作，但只能有一个线程参与这些行动 - 没有线程被阻塞在他们身上。

This shows how there can be only one thread involved (the UI thread), yet also have asynchronous operations going on. You can start up multiple asynchronous operations and yet only have one thread involved in those operations - no threads are blocked on them.

异步 / 等待提供了一个非常漂亮的语法开始异步操作，然后返回，并且具有其他该方法的该操作完成时继续进行。

async/await provides a very nice syntax for starting an asynchronous operation and then returning, and having the rest of the method continue when that operation completes.

ASP.NET是相似的，但它没有一个主/ UI线程。相反，它为每一个不完整的请求请求上下文。 ASP.NET线程来自一个线程池，他们进入请求上下文当他们发出请求;他们完成时，他们离开自己的请求上下文，并返回到线程池。

ASP.NET is similar, except it doesn't have a main/UI thread. Instead, it has a "request context" for every incomplete request. ASP.NET threads come from a thread pool, and they enter the "request context" when they work on a request; when they're done, they exit their "request context" and return to the thread pool.

ASP.NET跟踪不完整的异步操作的每个请求，所以当一个线程返回线程池，它会检查是否有该请求正在进行的任何异步操作;如果有没有，那么请求就完成了。

ASP.NET keeps track of incomplete asynchronous operations for each request, so when a thread returns to the thread pool, it checks to see if there are any asynchronous operations in progress for that request; if there are none, then the request is complete.

所以，当你的await ASP.NET中的一个不完整的异步操作，该线程将增加该计数器并返回。 ASP.NET知道由于计数器是非零的请求是不完整的，因此它没有完成的响应。该线程返回线程池，而在这一点上。还有的没有的线程上的请求工作

So, when you await an incomplete asynchronous operation in ASP.NET, the thread will increment that counter and return. ASP.NET knows the request isn't complete because the counter is non-zero, so it doesn't finish the response. The thread returns to the thread pool, and at that point: there are no threads working on that request.

当异步操作完成后，异步方法，将请求上下文它时间表剩余部分。 ASP.NET抓住其处理程序的一个线程（其可以是或可以不是被执行的异步方法的前面部分相同的线程），则计数器被递减，并线程执行异步方法。

When the asynchronous operation completes, it schedules the remainder of the async method to the request context. ASP.NET grabs one of its handler threads (which may or may not be the same thread that executed the earlier part of the async method), the counter is decremented, and the thread executes the async method.

ASP.NET vNext略有不同;还有在整个框架中的异步处理更多的支持。但总的概念是相同的。

ASP.NET vNext is slightly different; there's more support for asynchronous handlers throughout the framework. But the general concept is the same.

有关详细信息：

• 我的异步/等待开场后试图成为既有的简介的但也的相当完整的画面如何异步和的await 工作


• 异步/等待FAQ 有很多伟大的链接即进入了很多细节。


• MSDN杂志文章这是所有关于暴露了一些水管的下方的SynchronizationContext。

• My async/await intro post tries to be both an intro yet also reasonably complete picture of how async and await work.
• The official async/await FAQ has lots of great links that go into a lot of detail.
• The MSDN magazine article It's All About the SynchronizationContext exposes some of the plumbing underneath.

这篇关于如何不同的异步编程为主题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！