异步等待会增加上下文切换吗 [英] Does async await increases Context switching
问题描述
我知道异步等待的工作方式.我知道执行到达等待状态时，它将释放线程，IO完成后，它将从线程池中获取线程并运行其余代码.这样，可以有效地利用线程.但是在某些用例中我感到困惑:
I am aware of how async await works. I know that when execution reaches to await, it release the thread and after IO completes, it fetches thread from threadpool and run the remaining code. This way threads are efficiently utilized. But I am confused in some use cases:
- 对于高速IO方法(例如缓存读/写方法)，我们应该使用异步方法吗?它们是否会导致不必要的上下文切换.如果我们使用sync方法，则执行将在同一线程上完成，并且上下文切换可能不会发生.
- 是否异步等待仅节省内存消耗(通过创建更少的线程).还是也可以节省CPU?据我所知，在发生同步IO的情况下，发生IO时，线程会进入睡眠模式.这意味着它不消耗cpu.这种理解正确吗?
推荐答案
对于高速IO方法，我们应该使用异步方法，例如缓存读/写方法吗?
Should we use async methods for the very fast IO method, like cache read/write method?
在传统意义上，这样的IO不会阻塞. 阻止"是一个宽松定义的术语.通常，这意味着CPU必须等待硬件.
Such an IO would not block in the classical sense. "Blocking" is a loosely defined term. Normally it means that the CPU must wait for the hardware.
这种类型的IO纯粹是CPU工作，没有上下文切换.如果应用读取文件或套接字的速度比提供数据的速度慢，通常会发生这种情况.在这里，异步IO根本无法提高性能.我什至不确定取消阻塞UI线程是否合适，因为所有任务都可能同步完成.
This type of IO is purely CPU work and there are no context switches. This would typically happen if the app reads a file or socket slower than data can be provided. Here, async IO does not help performance at all. I'm not even sure it would be suitable to unblock the UI thread since all tasks might complete synchronously.
或者它也可以节省CPU?
Or it also saves cpu as well?
通常会增加实际负载中的CPU使用率.这是因为异步机制增加了处理，分配和同步.另外，我们需要两次而不是一次地转换到内核模式(首先启动IO，然后使IO完成通知出队).
It generally increases CPU usage in real-world loads. This is because the async machinery adds processing, allocations and synchronization. Also, we need to transition to kernel mode two times instead of once (first to initiate the IO, then to dequeue the IO completion notification).
典型的工作负载在<<<< 100％CPU生产CPU超过60％的服务器会使我担心，因为没有错误余地.在这种情况下，线程池工作队列几乎总是空的.因此，不会因为在一个上下文切换器上处理多个IO完成而节省上下文切换器.
Typical workloads run with <<100% CPU. A production server with >60% CPU would worry me since there is no margin for error. In such cases the thread pool work queues are almost always empty. Therefore, there are no context switching savings caused by processing multiple IO completions on one context switch.
这就是CPU使用率通常(略有增加)的原因，除非计算机的CPU负载很高，并且工作队列通常能够立即交付新项目.
That's why CPU usage generally increases (slightly), except if the machine is very high on CPU load and the work queues are often capable of delivering a new item immediately.
在服务器上，异步IO主要用于保存线程.如果有足够的线程可用，您将实现零收益或负收益.特别是任何一个IO都不会变得快一点.
On the server async IO is mainly useful for saving threads. If you have ample threads available you will realize zero or negative gains. In particular any single IO will not become one bit faster.
这意味着它不消耗CPU.
That means it does not consume cpu.
在进行IO时使CPU不可用将是一种浪费.对于内核来说，IO只是一种数据结构.在进行过程中，没有CPU工作要做.
It would be a waste to leave the CPU unavailable while an IO is in progress. To the kernel an IO is just a data structure. While it's in progress there is no CPU work to be done.
一个匿名人士说:
对于受IO约束的任务，仅使用单独的线程等待结果可能没有主要的性能优势.
For IO-bound tasks there may not be a major performance advantage to using separate threads just to wait for a result.
将相同的工作推送到不同的线程肯定对吞吐量没有帮助.这是添加的工作，而不是简化的工作.这是一个壳牌游戏. (而且异步IO在运行时不使用线程，因此所有这些都是基于错误的假设.)
Pushing the same work to a different thread certainly does not help with throughput. This is added work, not reduced work. It's a shell game. (And async IO does not use a thread while it's running so all of this is based on a false assumption.)
一种使自己确信异步IO通常比同步IO花费更多的CPU的简单方法是运行简单的TCP ping/pong基准同步和异步.同步速度更快.这是一种人为的负担，因此仅提示正在发生的事情，而不是进行全面的测量.
A simple way to convince yourself that async IO generally costs more CPU than sync IO is to run a simple TCP ping/pong benchmark sync and async. Sync is faster. This is kind of an artificial load so it's just a hint at what's going on and not a comprehensive measurement.
这篇关于异步等待会增加上下文切换吗的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
