最近、(再び) Tanenbaum の 'Modern Operating Systems 4ed' を読み始めましたが、プロセスとスレッドについて説明している第 2 章に少し行き詰まっています。特に、それらのすべての利点と欠点をリストしたユーザー空間スレッドのサブチャプターについて混乱しています。
ユーザー空間スレッドを支持する直接の引用は次のとおりです。
ユーザーレベルのスレッドには、他にも利点があります。これにより、各プロセスが独自のカスタマイズされたスケジューリング アルゴリズムを持つことができます。ガベージ コレクタ スレッドを使用するアプリケーションなど、一部のアプリケーションでは、都合の悪いときにスレッドが停止することを心配する必要がないという利点があります。また、カーネル スレッドは常にカーネル内のテーブル スペースとスタック スペースを必要とするため、スケーラビリティも向上します。これは、非常に多数のスレッドがある場合に問題になる可能性があります。
私が理解している方法は、スレッドを使用しているすべてのプロセス（したがって、それらを作成/破棄する）は、これらのスレッドを効率的にするためにこれらのスレッドのスケジューリングを実装する責任があるということです。たとえば、定義済みの短い時間間隔を使用した単純なラウンドロビン。
ただし、サブチャプターの後半で、欠点についての引用を取得します. ここに来ます：
ユーザーレベルのスレッド パッケージのもう 1 つの問題は、スレッドが実行を開始すると、最初のスレッドが自発的に CPU を放棄しない限り、そのプロセスの他のスレッドが実行されないことです。1 つのプロセス内では、クロックの割り込みがないため、プロセスをラウンドロビン方式 (交代) でスケジュールすることはできません。スレッドがそれ自体の自由意志でランタイム システムに入らない限り、スケジューラにチャンスはありません。
うーん、なんと？したがって、長所では、プロセスのスレッド用の独自のスケジューラーを使用することは利点です。ここでは、カスタマイズされたスケジューラーがあっても、スレッドが貪欲であるため、期待どおりに機能しないようです。
私の質問は次のとおりです。ユーザー空間スレッドを使用して実際にスレッドを同じようにスケジュールする場合、プロセスのスケジューラーは不可能ですか? それとも、ここで要点をつかむには私の英語力が足りないのでしょうか。
PS。投稿された質問を確認するとき、これを読むように提案されました - User-level threads for threading。タネンバウムのモデルが古いシステムに適用可能だったというのは正しいことではないでしょうか? この本は2014年にリリースされたので、それは問題かもしれません.