なぜ共同スケジュールを選択しないのですか?

なぜ共同スケジュールを選択しないのですか?

オペレーティングシステムの概念

CPUスケジューリングの決定は、次の4つの状況で発生する可能性があります。

  1. プロセスが実行状態から待機状態に遷移する場合(たとえば、I / O要求または子プロセスを終了するためのwait()呼び出しによる)

  2. プロセスが実行中状態から準備状態に遷移する場合(たとえば、割り込みが発生した場合)

  3. プロセスがスタンバイから準備に移行する場合(例:I / Oが完了した場合)

  4. プロセスが終了したとき

ケース1とケース4の場合スケジュール選択不可。実行するには、新しいプロセス(準備キューに存在する場合)を選択する必要があります。一つある 選ぶただし、2番と3番の場合。

スケジューリングがケース1と4でのみ発生する場合、スケジューリング方式は非プリエンプティブまたはコラボレーションです。そうでなければ先制攻撃になるだろう。

「スケジュール選択」とはどういう意味ですか?

協力的なスケジューリングを選択していませんが、プリエンプティブスケジューリングが可能なのはなぜですか?

私の考えでは、スケジューリングが先制的であるかどうかにかかわらず、

  • 実行中のプロセスは常にCPUを放棄し(したがって選択の余地はありません)

  • 実行する準備ができたキューからプロセスを選択する選択は常に可能です。

ありがとうございます。

答え1

記事に他の選択肢がない場合、

実行するには、新しいプロセス(準備キューに存在する場合)を選択する必要があります。

私は、これが議論されている選択肢が次にどのプロセスが予定されているかを直接含めるのではなく、むしろ検討中のプロセスがスケジュールされることができるかどうかを意味することを受け入れます。 1番と4番の場合は不可能です。 2番と3番の場合にはそうです。

ここで使用されている協同的対先占型という用語は私にとって奇妙に見えます。共同スケジュールは通常、プロセスが自発的に制御を放棄することを意味しますが、「ブロックされた」および「終了した」を共同スケジュールとして解釈することは私にとって無理なようです。

答え2

ケース 1 と 4 の場合、プロセスには何もしないので (ケース 1 ではまだ、ケース 4 ではまだではない) スケジューラを実行できません。つまり、選択の余地はありません:実行または実行しない...常に実行されません。 2番と3番の場合、スケジューラが「このプロセスを実行するか、他のプロセスを実行するか」を決定する必要があるため、選択が可能です。ただし、プリエンプティブスケジューラだけがそのような選択を行うことができ、コラボレーションスケジューラは実行中のプロセスが状態1になるのを待ちます。 (つまり、i / oまたは降伏を待っています)または4(成功的に終了したかエラーで終了しました)

関連情報