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 。