了解POSIX和Linux / glibc sched_ *函数之间的差异

Question

POSIX XSH 2.8.4 Process Scheduling定义了线程和进程的调度属性的行为。指定sched_*接口会影响进程的调度属性，而不影响线程。这在以下段落中阐明：

  

POSIX模型将“进程”视为系统资源的聚合，包括可由操作系统在其控制的处理器上调度的一个或多个线程。虽然进程有自己的一组调度属性，但它们对各个线程的调度行为有间接影响（如果有的话），如下所述。

和

  

对于具有系统调度争用范围的线程，进程调度属性不应对线程或专用于该线程的底层内核调度实体的调度属性或行为产生影响。

我对此的解读是，在只支持“系统调度争用范围”的系统上（Linux / glibc就是这样一个系统），sched_*函数应该绝对没有可观察到的影响。

这与Linux / glibc上当前行为的实际情况相反，其中sched_*设置了特定线程的调度属性。

除了想要更好地理解这种情况之外，我想我有这些关键问题：

1. 是否有任何关于这种差异的理由的文件？

2. 我对标准的阅读是否正确？特别是，对于我而言，sched_setparam和sched_setscheduler被指定为在单线程应用程序中没有任何效果（主线程使用默认调度策略，无法更改）和系统争用范围）。

3. 标准sched_*功能的用处是什么？在我看来，它们对大多数实现没有影响，即使对支持进程争用范围的实现也没有影响。有人可以描述它们的用途吗？

Answer 1

我认为原因在于，自NPTL实施之前就已经采用了这种方式，没有人为内核提供线程组调度属性支持，因此这些函数仍然可以完成他们一直以来的工作。 / p>

可能因为，正如你所指出的那样，POSIX指定它们的方式在没有进程争用范围的情况下根本不会有用......

Answer 2

Linux中sched_setparam等行为的基本原理是线程实际上是由clone(2)系统调用创建的进程，参见glibc/nptl/sysdeps/pthread/createthread.c。