13

POSIX XSH 2.8.4 进程调度定义了线程和进程调度属性的行为。sched_*指定接口以影响进程的调度属性，而不是线程。这在以下段落中得到了澄清：

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

和

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

我对此的解读是，在仅支持“系统调度争用范围”的系统上（Linux/glibc 就是这样的系统），这些sched_*函数应该绝对没有明显的影响。

sched_*这与在 Linux/glibc 上设置特定线程的调度属性的当前行为的现实相反。

除了想更好地理解这种情况，我想我还有以下关键问题：

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

  2. 我对标准的阅读是否正确？特别是，这对我来说似乎真的很令人惊讶，sched_setparam并且sched_setscheduler会被指定为在单线程应用程序中无效（其中主线程使用默认调度策略，无法更改，并且系统争用范围）。

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

4

2 回答 2

1

我相信原因是在 NPTL 实施之前就一直这样，没有人为内核贡献线程组范围的调度属性支持，所以这些函数仍然在做他们一直在做的事情。

并且可能是因为，正如您所指出的，如果没有进程争用范围，POSIX 指定它们的方式根本就没有用......

于 2014-01-19T04:47:14.753 回答
0

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

于 2012-11-21T14:10:22.653 回答