是否为相同优先级的进程分配了相同的时间片？
我知道这取决于操作系统，但是在现代操作系统中，是否为相同优先级的线程/进程提供了相同的时间片，或者是否涉及其他因素？
I know this is dependant on the operating system, but in modern operating systems, are equal time slices given to threads/processes of the same priority, or are there other factors involved?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果线程正在执行 I/O、等待同步机制或将要休眠，则它们可以使用比直接计算所使用的时间片更少（有时甚至更多）的时间片。操作系统尽力为具有相同线程/进程优先级的线程提供相同的时间量，但实际上给出的实际时间可能会有所不同。
例如，一个线程几乎将其全部（墙）时间都花在等待退出事件上，平均而言（在其总运行时间内）将比执行相同量计算的同等优先级的线程获得更少的时间（墙）时间。
If the threads are doing I/O, waiting on synchronization mechanisms, or are going to sleep, they can use less (and sometimes more) than the timeslice they would use doing straight computation. The OS tries its best to give threads with identical thread/process priority the same quantum, but in reality the actual time given can vary.
For example, a thread that spends practically its entire (wall) time sleeping waiting on an exit event is going to be given less time, on average (over its total run), than one of equal priority that is doing compuation for the same amount of (wall) time.
在 Linux 中，对于同等优先级进程，抢占式调度程序
运行等待时间最长的进程。
在 Windows 中，每个优先级都有 FIFO 队列和一个线程
可以切换优先级队列：
– 如果线程由于时间片已到而中断，则优先级降低
– 如果中断等待 I/O 事件，则优先级提高
– 优先考虑 I/O 密集型线程而不是 CPU 密集型线程
– 对于 I/O 绑定线程，交互优先级提高更多
等待（例如键盘、显示器）优于其他 I/O（例如磁盘）
In Linux for equal-priority processes, the preemptive scheduler
runs the process waiting the longest.
In Windows it's FIFO queue at each priority level and a thread
can switch priority level queues:
– if thread interrupted because time slice is up, priority lowered
– if interrupted to wait on I/O event, priority raised
– favors I/O-bound over CPU-bound threads
– for I/O bound threads, priority raised more for interactive
waits (e.g. keyboard, display) than for other I/O (e.g. disk)