异步等待增加上下文切换

Question

我知道异步等待是如何工作的。 我知道当执行到达等待时，它释放线程并在IO完成后，它从线程池中获取线程并运行剩余的代码。 这样就可以有效地利用线程。 但我在一些用例中感到困惑：

1. 我们是否应该使用异步方法来实现非常快速的IO方法，比如缓存读/写方法？ 它们不会导致不必要的上下文切换。 如果我们使用sync方法，则执行将在同一线程上完成，并且上下文切换可能不会发生。
2. Async-await是否仅保存内存消耗（通过创建较少的线程）。 或者它也节省了CPU？ 据我所知，在同步IO的情况下，当IO发生时，线程进入睡眠模式。 这意味着它不消耗CPU。 这种理解是否正确？

Answer 1

我知道异步等待是如何工作的。

你不是。

我知道当执行到达等待时，它会释放线程

它不是。 当执行到达等待时，将评估等待的操作数，然后检查操作是否完成。 如果不是，那么该方法的其余部分被注册为等待的继续，并且表示当前方法的工作的任务被返回给调用者。

这些都不是“释放线程”。 相反， 控制返回给调用者 ，调用者继续在当前线程上执行。 当然，如果当前调用者是这个线程上的唯一东西，那么线程就完成了。 但是并不要求异步方法是线程上的唯一调用！

IO完成后

等待的不一定是IO操作，但我们假设它是。

它从线程池中获取线程并运行剩余的代码。

不会 。它会安排剩余的代码在正确的上下文中运行 。 该上下文可能是一个线程池线程。 它可能是UI线程。 它可能是当前的线程。 它可能是任何数量的东西。

我们是否应该使用异步方法来实现非常快速的IO方法，比如缓存读/写方法？

等待评估。 如果等待者知道它可以在合理的时间内完成操作，则完全有权进行操作并返回完成的任务。 在这种情况下，没有罚款; 你只是检查一个布尔值来查看任务是否完成。

它们不会导致不必要的上下文切换。

不必要。

如果我们使用sync方法，则执行将在同一线程上完成，并且上下文切换可能不会发生。

我很困惑为什么你认为在IO操作上发生了上下文切换。 IO操作在硬件上运行，低于OS线程级别。 没有任何线程可以为IO任务提供服务。

Async-await是否仅保存内存消耗（通过创建较少的线程）

等待的目的是（1）通过允许工作流变得更加异步，从而在等待高延迟结果的同时释放线程来工作，以及（2）制作源代码，从而更有效地使用昂贵的工作线程异步工作流程类似于同步工作流程的源代码。

据我所知，在同步IO的情况下，当IO发生时，线程进入睡眠模式。 这意味着它不消耗CPU。 这种理解是否正确？

当然，你完全倒退了。 你想要消耗CPU 。 你想要一直消耗尽可能多的CPU！ 该CPU是做代表用户的工作 ，如果是闲置那么它没有得到它的工作速度，因为它可以完成。 不要雇佣工人，然后付钱让他们入睡！ 雇用一名工人，一旦他们被阻塞在高延迟任务上，就让他们去做其他工作，这样 CPU就会一直保持热度。 该机器的所有者为该CPU支付了很多钱; 它应该始终以100％运行才能完成工作！

那么让我们回到你的基本问题：

异步等待增加上下文切换

我知道一个很好的方法可以找到答案。 使用await编写程序，不用编写另一个程序，同时运行它们 ，并测量每秒的上下文切换次数。 然后你就会知道。

但我不明白为什么每秒上下文切换是一个相关的指标。 让我们考虑两家拥有大量客户和大量员工的银行。 在银行＃1，员工完成一项任务直至完成; 他们从不改变背景。 如果员工在等待另一个员工的结果时被阻止，他们会进入睡眠状态。 在银行＃2，员工在被阻止时从一个任务切换到另一个任务，并且不断地为客户请求提供服务。 您认为哪家银行有更快的客户服务？

Answer 2

我们是否应该使用异步方法来实现非常快速的IO方法，比如缓存读/写方法？

这样的IO不会在经典意义上阻止。 “阻止”是一个松散定义的术语。 通常，这意味着CPU必须等待硬件。

这种类型的IO纯粹是CPU工作，没有上下文切换。 如果应用程序读取文件或套接字的速度慢于可以提供的数据，则通常会发生这种情况。 在这里，异步IO根本无助于性能。 我甚至不确定是否适合解除UI线程的阻塞，因为所有任务可能同步完成。

或者它也节省了CPU？

它通常会增加实际负载中的CPU使用率。 这是因为异步机器增加了处理，分配和同步。 此外，我们需要转换到内核模式两次而不是一次（首先启动IO，然后将IO完成通知出列）。

典型工作负载使用<< 100％CPU运行。 具有> 60％CPU的生产服务器会担心我，因为没有错误余量。 在这种情况下，线程池工作队列几乎总是空的。 因此，在一个上下文切换上处理多个IO完成不会导致上下文切换节省。

这就是为什么CPU使用率通常会增加（略微），除非机器的CPU负载非常高并且工作队列通常能够立即提供新项目。

在服务器上，异步IO主要用于保存线程。 如果您有足够的线程可用，您将实现零或负增益。 特别是任何单个IO都不会快一点。

这意味着它不消耗CPU。

在IO正在进行时，让CPU不可用将是一种浪费。 对内核而言，IO只是一种数据结构。 在它正在进行的过程中，没有CPU工作要做。

一位匿名人士说：

对于IO绑定任务，使用单独的线程来等待结果可能没有主要的性能优势。

将相同的工作推送到不同的线程肯定无助于吞吐量。 这是增加的工作，而不是减少工作。 这是一个贝壳游戏。 （并且async IO在运行时不使用线程，因此所有这些都基于错误的假设。）

一个简单的方法来说服自己异步IO通常比同步IO花费更多的CPU是运行简单的TCP ping / pong基准同步和异步。 同步更快。 这是一种人为的负载，所以它只是暗示正在发生的事情，而不是一个全面的测量。