ラウンドロビンの問題は、タスクが等しくないことです。
CPUバウンドタスクの場合。非常に重要なタスクと何千もの重要でないタスクがある場合、それらの重要でないタスクはすべて、重要なタスクのパフォーマンスを低下させます。この場合、タイムスライスの大きさは関係ありません。
IOバウンドタスクの場合、ラウンドロビンは遅延を引き起こします。重要なタスクのブロックが解除された場合(たとえば、「sleep()」を呼び出した後にウェイクアップしたり、待機していたファイルIOを受信したりするなど)、重要なタスクの前に、何千もの重要でないタスクがタイムスライスを通過するのを待たなければならない場合があります。何でもするチャンスがあります。タイムスライスの長さを短くすると、重要なタスクが何か有用なことを開始するまでにかかる時間が短縮されますが、重要なタスクが何か有用なことを実行できるようになるまでの時間も短縮されます。
注:ブロックを解除するタスクをリストの先頭に移動させることで、これを「修正」したくなる場合があります。この場合、重要でないタスクが眠り、目覚め続けるという理由だけで、重要なタスクが永遠に飢えている可能性があります。
基本的に、ラウンドロビンは「役に立たない」ものの山であり、さまざまなタスクの重要性/優先度を少なくともある程度尊重する完全に異なるスケジューリングアルゴリズムに置き換えるまで、何をするかは重要ではありません。
過度に単純化された例の場合。3つの異なるタスク優先度を設定できます。この場合、OSは可能な限り最高の優先度のタスクのみを実行し(優先度の高いタスクが優先度の低いタスクをすぐにプリエンプトすることを確認するなど)、同じ優先度のタスクにラウンドロビンが使用されます。この場合、優先度ごとにタイムスライスの長さを変えることができます(たとえば、優先度の高いタスクは1ミリ秒、優先度の低いタスクは10ミリ秒、優先度の低いタスクは125ミリ秒)。
「あまり単純化されていない」例の場合。いくつかの完全に異なるスケジューリングポリシー(たとえば、リアルタイムタスク用、通常タスク用、バックグラウンド/アイドルタスク用)を設定できます。これらはすべて異なるアプローチ(たとえば、最も早い期限、可変タイムスライスなど)を使用します。ここで、各スケジューリングポリシーには256のタスク優先順位があります。