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

R..*_*R.. 13 c linux posix scheduling

POSIX XSH 2.8.4进程调度定义了线程和进程的调度属性的行为.所述sched_*接口被指定为影响的调度特性过程,而不是线程.这在以下段落中阐明:

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

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

我对此的解读是,在只支持"系统调度争用范围"的系统上(Linux/glibc就是这样一个系统),这些sched_*函数应该绝对没有可观察到的效果.

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

除了想要更好地了解这种情况外,我想我有以下几个关键问题:

  1. 有没有关于这种差异的理由的文件?

  2. 我的标准阅读是否正确?特别是,对我来说这似乎真的很令人惊讶,sched_setparam并且sched_setscheduler将被指定在单线程应用程序中没有任何效果(主线程使用默认调度策略,无法更改,以及系统争用范围).

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

chi*_*ill 0

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

  • “线程实际上是进程”是一句老话,但实际上并不正确。进程就是内核所说的“线程组”,它们与线程完全不同。但是,在添加这些接口时,您所说的可能仍然是“正确的”;让他们做错误事情的原因可能只是现有的应用程序使用情况。然而,鉴于 NPTL 修复了 LinuxThreads 中的大部分不正确语义,这个问题也没有得到修复似乎很奇怪...... (2认同)