异步任务 - CPU 上实际发生了什么？

Question

在询问this question 并看到我完全误解了这个概念后，我一直在阅读有关Tasks 的信息。诸如置顶答案here 和here 之类的答案解释了idea，但我还是不明白。 所以我提出了一个非常具体的问题：在执行任务时，CPU 上实际发生了什么？

这是我在阅读后所理解的：任务将与调用者共享 CPU 时间（假设调用者是“UI”），因此如果它是 CPU 密集型的 - 它会减慢 UI。如果任务不是 CPU 密集型 - 它将在“后台”运行。看起来很清楚……直到经过测试。下面的代码应该允许用户点击按钮，然后交替显示“Shown”和“Button”。但实际上：在“已显示”全部显示之前，表单一直处于忙碌状态（-不可能有用户输入）。

public Form1()
{
    InitializeComponent();
    Shown += Form1_Shown;
}

private async void Form1_Shown(object sender, EventArgs e)
{
    await Doit("Shown");
}

private async Task Doit(string s)
{
    WebClient client = new WebClient();
    for (int i = 0; i < 10; i++)
    {
        client.DownloadData(uri);//This is here in order to delay the Text writing without much CPU use.
        textBox1.Text += s + "\r\n";
        this.Update();//textBox1.
    }
}

private async void button1_Click(object sender, EventArgs e)
{
    await Doit("Button");
}

有人可以告诉我在执行任务时 CPU 上实际发生了什么（例如“当 CPU 不被 UI 使用时，任务会使用它，除非……等”）？

Answer 1

理解这一点的关键是有两种任务 - 一种执行代码（我称之为委托任务），一种代表未来的事件（我称之为承诺任务）。这两个任务完全不同，尽管它们都由 .NET 中的 Task 实例表示。我有一些pretty pictures on my blog 可能有助于了解这些类型的任务有何不同。

委托任务是由Task.Run 和朋友创建的。它们在线程池上执行代码（如果您使用的是TaskFactory，则可能是另一个TaskScheduler）。大多数“任务并行库”文档都处理委托任务。这些用于在多个 CPU 之间传播受 CPU 限制的算法，或将受 CPU 限制的工作推离 UI 线程。

Promise 任务是由TaskCompletionSource<T> 和朋友（包括async）创建的。这些是用于异步编程的代码，非常适合 I/O 绑定代码。

请注意，您的示例代码将导致编译器警告，大意是您的“异步”方法Doit 实际上不是异步的，而是同步的。所以就目前而言，它将同步调用DownloadData，阻塞UI线程直到下载完成，然后它会更新文本框并最终返回一个已经完成的任务。 p>

要使其异步，您必须使用await：

private async Task Doit(string s)
{
  WebClient client = new WebClient();
  for (int i = 0; i < 10; i++)
  {
    await client.DownloadDataTaskAsync(uri);
    textBox1.Text += s + "\r\n";
    this.Update();//textBox1.
  }
}

现在它在遇到await 时返回一个不完整的任务，这允许 UI 线程返回到它的消息处理循环。下载完成后，此方法的其余部分将作为消息排队到 UI 线程，并在处理该方法时继续执行该方法。当Doit方法完成后，它之前返回的任务就会完成。

因此，async 方法返回的任务在逻辑上代表该方法。任务本身是 Promise Task，而不是 Delegate Task，实际上并不“执行”。该方法分为多个部分（在每个await 点）并以块的形式执行，但任务本身不会在任何地方执行。

为了进一步阅读，我在how async and await actually work (and how they schedule the chunks of the method) 上有一篇博文，在why asynchronous I/O tasks do not need to block threads 上有另一篇博文。

Answer 2

根据您链接的答案，任务和线程是完全不同的概念，您也对异步/等待感到困惑

Task 只是表示要完成的一些工作。它没有说明应该如何完成工作。

Thread 表示在 CPU 上运行的某些工作，但它与它一无所知的其他线程共享 CPU 时间。

您可以使用Task.Run() 在Thread 上运行Task。您的Task 将异步运行，并且独立于任何其他提供线程池线程的代码。

您还可以使用 async / await 在 SAME 线程上异步运行任务。每当线程遇到等待时，它都可以保存当前的堆栈状态，然后返回堆栈并继续其他工作，直到等待的任务完成。您的 Doit() 代码从不等待任何内容，因此将在您的 GUI 线程上同步运行直到完成。

Answer 3

任务使用ThreadPool，您可以广泛阅读它是什么以及它是如何工作的here

但简而言之，当一个任务被执行时，任务调度器会在ThreadPool 中查看是否有线程可用于运行该任务的动作。如果没有，它将排队，直到有一个可用。

ThreadPool 只是一组已经实例化的可用线程，因此多线程代码可以安全地使用并发编程，而不会一直因上下文切换而使 CPU 不堪重负。

现在，您的代码的问题在于，即使您返回 Task 类型的对象，您也没有同时运行任何东西 - 从未启动过单独的线程！

为了做到这一点，您有两个选择，或者您将Doit 方法作为任务启动，使用

选项1

Task.Run(() => DoIt(s));

这将在线程池中的另一个线程上运行整个DoIt 方法，但这会导致更多问题，因为在此方法中，您正在尝试访问 UI 控件。因此，您需要将这些调用编组到 UI 线程，或重新考虑您的代码，以便在异步任务完成后直接在 UI 线程上完成 UI 访问。

---

选项 2（最好，如果可以的话）

您使用 已经异步的 .net API，例如 client.DownloadDataTaskAsync(); 而不是 client.DownloadData();

现在，就您而言，问题是您需要进行 10 次调用，这些调用将返回 10 个不同类型的 Task<byte[]> 对象，并且您希望等待所有对象完成，而不仅仅是一个.

为此，您需要创建一个List<Task<byte[]>> returnedTasks，并将DownloadDataTaskAsync() 的所有返回值添加到其中。然后，一旦完成，您就可以为您的 DoIt 方法使用以下返回值。

return Task.WhenAll(returnedTasks);