了解POSIX和Linux / glibc调度之间的差异
POSIX XSH 2.8.4进程调度定义线程和进程的调度属性的行为。 sched_*接口被指定为影响进程的调度属性，而不是线程。 这在下面的段落中得到澄清：
POSIX模型将“进程”视为系统资源的集合，包括可由操作系统在其控制的处理器上调度的一个或多个线程。 尽管一个进程具有自己的一组调度属性，但它们对各个线程的调度行为有间接影响（如果有的话），如下所述。
和
对于具有系统调度竞争范围的线程，进程调度属性不应该对线程或专用于该线程的底层内核调度实体的调度属性或行为有影响。
我读到的是，在只支持“系统调度竞争范围”的系统上（Linux / glibc就是这样一个系统）， sched_*函数应该完全没有可观察到的影响。
这与Linux / glibc上当前行为的实际情况相反，其中sched_*设置特定线程的调度属性。
除了想更好地理解这种情况，我想我有这些关键问题：
有没有关于这种差异的理由的文件？
我对标准的阅读是否正确？ 特别是，对于我来说， sched_setparam和sched_setscheduler被指定为在单线程应用程序（主线程使用默认调度策略，不能更改以及系统争用范围）中不起作用，这似乎真的令人惊讶。
标准的sched_*函数有什么用处？ 在我看来，它们对大多数实现没有任何影响，即使对支持进程竞争范围的实现影响也很小。 有人可以描述他们的使用目的吗？
我相信原因在于自从NPTL实施之前就已经是这样了，没有人为内核贡献线程组范围的调度属性支持，所以这些功能仍然完成他们一直以来的工作。
可能是因为，正如你所指出的那样，POSIX指定它们的方式在没有进程竞争范围的情况下并不会真正有用......
Linux中sched_setparam等行为的基本原理是线程实际上是由clone(2)系统调用创建的进程，参见参考资料。 glibc/nptl/sysdeps/pthread/createthread.c 。
上一篇: Understanding discrepancy between POSIX and Linux/glibc sched