【发布时间】：2014-02-24 10:19:10
【问题描述】：
考虑以下场景： 在 POSIX 系统中，来自用户程序的某些线程正在运行并且 timer_interrupt 已被禁用。
据我了解，除非它终止 - 当前运行的线程不会自愿放弃对 CPU 的控制。 我的问题如下：从线程内调用 pthread_yield() 是否会让内核控制 CPU？
对于这个问题的任何帮助将不胜感激。
【问题讨论】：
标签： pthreads kernel posix interrupt
【发布时间】：2014-02-24 10:19:10
【问题描述】：
关闭操作系统的定时器中断将把它变成一个协作多任务系统。这就是 Windows 1、2、3 和 Mac OS 9 的工作方式。只有当程序进行系统调用时，运行的任务才会发生变化。
由于 pthread_yield 导致系统调用，是的，内核将从程序中取回控制权。
如果您在协作式多任务系统上编写程序，那么非常重要不要占用 CPU。如果您的程序确实占用了 CPU，整个系统就会停止。
这就是 Windows MFC 在其消息循环中具有空闲消息的原因。执行长期任务的程序将在该消息处理程序中执行此操作，方法是操作一两个项目，然后返回操作系统以检查用户是否单击了某些内容。
【讨论】：
-
不太合作，不。来自许多其他驱动程序之一的硬件中断仍然可以请求调度运行并生成上下文更改，从而导致正在运行的线程被抢占。
-
@MartinJames：我并不肯定，但我相信 Windows 3 也发生了这种情况。
-
Win3 确实是合作的，非常绝望。抢先式多任务最早出现在 W95 上，大大提高了 I/O 性能，（但不是稳定性，众所周知：）。 Windows 到了，（非常），低点与令人震惊的我。借助 NT/W2K，Windows 获得了 32 位保护模式的稳定性和抢先式多任务处理的高性能 I/O，使其非常实用。
-
'如果你的程序确实占用了 CPU，整个系统就会停止' - 不，它不必这样做，因为其他硬件中断。我很想对此投反对票，但我今天心情很好:)
-
@MartinJames：您确实使用过 Win 3.1，不是吗？如果你为它开发，你就会知道如果你遇到了一个死循环，整个系统就会停止。 Ctrl-Alt-Delete 是拯救你的唯一方法。现在，技术上我想磁盘中断仍在运行，但实际上并没有什么区别。
它可以通过发出执行阻塞线程间通信或请求 I/O 的系统调用轻松放弃控制。多线程操作系统不一定需要定时器中断，但它对于为此类系统调用提供超时以及在系统因就绪线程过载时提供帮助非常有用。
【讨论】：
-
你好，马丁。感谢您花时间回答我的问题。据我了解，在 UNIX 中，负责重新调度的系统例程是 schedualer_tick()，它是从 timer_interrupt 调用的。如果 timer_interrupt 被禁用——调用 pthread_yield() 会导致将 CPU 的控制权交给内核吗？这种方式允许新进程使用CPU？
-
@guy.gc - 可能会，也可能不会。如果就绪线程数少于核心数，yield() 可能会直接返回而不更改任何内容。定时器中断仅在就绪线程多于内核时才真正影响调度，或者在大多数未超载的系统上更有可能在某些 I/O、线程间同步或睡眠系统调用超时时影响调度。请注意，在大多数系统上，定时器中断只是可以请求调度运行的众多中断驱动驱动程序之一。