POSIXとLinux/glibc sched_ *関数の不一致を理解する

Question

POSIX XSH 2.8.4 Process Schedulingは、スレッドとプロセスのスケジューリング属性の動作を定義します。 sched_*インターフェイスは、スレッドではなくプロセスのスケジューリングプロパティに影響するように指定されています。これは、次の通路で明らかにされている：

POSIXモデルは、プロセッサ（単数または複数）上のオペレーティング・システムによってスケジューリングされてもよい1つ以上のスレッドを含むシステム・リソースの集合としての「プロセス」を扱い、それが制御します。プロセスには独自のスケジューリング属性のセットがありますが、以下に説明するように、個々のスレッドのスケジューリング動作に間接的な影響があります（存在する場合）。

と

システムのスケジューリング競合範囲とスレッドの場合、プロセススケジューリング属性は、スレッドまたはそのスレッド専用の基盤となるカーネルのスケジューリング実体のいずれかのスケジューリング属性や行動に影響を与えないものとします。

本の私の読書は、「システムのスケジューリング競合範囲が」サポートされているシステム（Linuxでは/ glibcのは、このようなシステム）上で、sched_*機能は全く観察可能な効果を持つべきではない、ということです。

これは、Linux/glibcの現在の動作の現実に反して、sched_*が特定のスレッドのスケジューリング属性を設定しています。

別に良く、一般的にこのような状況を理解したいから、私はこれらの重要な質問があると思います：

1. は、この矛盾の理論的根拠の任意のドキュメントはありますか？

2. 標準の読みは正しいですか？特に、sched_setparamとsched_setschedulerは、シングルスレッドアプリケーション（メインスレッドがデフォルトスケジューリングポリシーを使用していて変更できない、システム競合スコープを使用している）で効果がないことが指定されています。

3. 標準のsched_*関数の有用性は何ですか？ほとんどの実装には何の影響も及ぼさず、プロセスの競合範囲をサポートする実装でさえも最小限の効果があります。誰かが彼らの意図された使用法を記述できますか？

Answer 1

sched_setparamなどのLinuxでの動作のための理論的根拠は、スレッドがclone(2)システムコール、参照によって作成された実際のプロセスであるということですglibc/nptl/sysdeps/pthread/createthread.c。

Answer 2

私は、NPTLが実装される前からこの方法があり、誰もスレッドグループ全体のスケジューリング属性のサポートをカーネルに提供していないので、これらの機能は今でもやっていることをやっていると思います。

あなたが指摘したように、POSIXがそれらを指定する方法は、プロセスの競合範囲＆hellipなしでは本当に役に立たないからです。