上下文在睡眠/等待线程上切换 [英] Context Switches on Sleeping/Waiting Threads

问题描述

我试图了解操作系统如何处理不同模型中的上下文切换，以更好地理解为什么在请求数量高峰时NIO性能会更好.除了可能会限制线程数这一事实之外，我很好奇如何在如此大量的请求中执行阻塞操作会如何影响资源利用率.

I'm trying to understand how operating systems handle context switching in different models to better understand why NIO performance is better in cases of large peaks in the number of requests. Apart from the fact that there may be a limit to the number of threads, I'm curious how blocking operations being done in those large number of requests can affect resource utilization.

在每个线程模型一个请求中，例如一个基于Servlet 2.5的Web应用程序，如果499个线程正在等待数据库IO并且仅一个线程需要工作，则OS上下文是否会在试图找到一个的这500个线程之间切换需要工作吗?要执行上下文切换，操作系统必须存储当前线程的状态，并恢复下一个线程的状态.这样做之后，操作系统将发现它不需要任何CPU时间，并且会一直进行上下文切换，直到找到需要工作的线程为止. 另外，就服务器利用率而言，这看起来像什么? CPU低吗，因为它主要受交换上下文进出而不是实际计算任何东西的IO成本的束缚?

In a one request per thread model, say a servlet 2.5 based web application, if 499 threads are waiting for database IO and only one thread needs work, does the OS context switch between all of those 500 threads trying to find the one that needs work? To perform a context-switch, the operating system has to store the current thread's state, and restore the next thread's state. After doing so, the OS will find that it doesn't need any CPU time and will keep context switching until it finds the thread that needs work. Also, what does this look like in terms of server utilization? Is the CPU low as it's mostly just bound by the IO cost of swapping contexts in and out instead of actually computing anything?

在此先感谢您的帮助.如果您能指出我在书籍，教科书等方面的方向，我也将不胜感激.

Thanks in advance for any help. If you can point me in the direction of books, textbooks etc I would really appreciate that as well.

推荐答案

如果499个线程正在等待数据库IO，则仅需要一个线程 工作，操作系统上下文是否会在所有这500个线程之间切换 试图找到需要工作的人?

If 499 threads are waiting for database IO and only one thread needs work, does the OS context switch between all of those 500 threads trying to find the one that needs work?

如果操作系统的调度程序设计合理，则不会；一直在系统的所有线程上进行迭代，效率极低.

Not if the OS's scheduler has a sane design; iterating over all of the system's threads all of the time would be terribly inefficient.

相反，大多数调度程序实现都保留一个睡眠/阻塞线程列表和一个单独的就绪运行"线程列表.当发生应该唤醒线程的事件时(例如，传入的数据在套接字或文件句柄上变得可用，或者释放了被阻塞线程的互斥锁)，操作系统会将线程从休眠/阻塞状态移至线程列表到ready-threads列表.然后，当需要执行上下文切换时，操作系统从ready-threads-list中选择一个线程，在该线程的上下文中加载并开始运行它.在任何现代/流行的OS中，sleeping/blocked-threads-list的大小完全不会影响调度程序从ready-threads-list中选择一个线程运行的时间. (在某些操作系统下，ready-threads-list的大小可能会产生影响，但是某些调度程序的设计目的是，即使具有许多就绪线程的系统也不会导致调度程序的效率降低)

Instead, most scheduler implementations keep a list of sleeping/blocked threads and a separate list of "ready-to-run" threads. When an event occurs that is supposed to wake up a thread (e.g. incoming data becomes available on a socket or file-handle, or a mutex that the thread was blocked on is released), the OS moves that thread from the sleeping/blocked-threads-list to the ready-threads-list. Then, when it is time to perform a context switch, the OS chooses a thread from the ready-threads-list, loads in that thread's context, and starts running it. In any modern/popular OS, the size of the sleeping/blocked-threads-list will have no impact at all on the time it takes the scheduler to select a thread from the ready-threads-list to run. (the size of the ready-threads-list might have an impact, under some OS's, but some schedulers are designed so that even a system with many ready-threads won't cause the scheduler to become less efficient)

CPU是否较低，因为它主要受交换的IO成本约束 上下文输入和输出而不是实际计算任何东西?

Is the CPU low as it's mostly bound by the IO cost of swapping contexts in and out instead of actually computing anything?

假设您还没有用完RAM，那么切换线程上下文就不会涉及I/O了.上下文切换仅涉及CPU和RAM.如果CPU使用率较低，则最可能的原因是线程的算法本身受I/O约束(例如，大多数情况下，大多数情况下大多数事情都在网络卡或硬盘驱动器上等待).如果您的线程实际上没有执行任何I/O，并且您仍然受I/O约束，则可能表明您的计算机已用完所有可用RAM，并且

Assuming you haven't run out of RAM, there is no I/O involved in switching thread contexts; context-switching involves the CPU and RAM only. If the CPU usage is low, the most likely reason is that your threads' algorithms themselves are I/O bound (e.g. most everything is waiting on your network card or hard drive to read or write data, most of the time). If your threads don't actually do any I/O, and you're still I/O bound, that might be a sign that your computer has used up all of its available RAM and is thrashing -- not a good state to be in.

这篇关于上下文在睡眠/等待线程上切换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！