RTOSが決定論的であると見なされるのはなぜですか？

PC（もちろんOS）では、どのCプログラムもタイミングの点で不確定になります。たとえば、「別のウィンドウを移動する速さ」に応じて、ループは1.2〜1.3秒かかります。これは、OSがプロセス（またはスレッド）に処理能力を共有させるためです。

RTOSに関する限り（組み込みシステム上）、マルチスレッドアプリケーションを作成すると、同時に実行されているスレッドの数に応じて、同じことが起こると思います。

組み込みシステムでこれを正確にテストするための機器がありません。したがって、私は尋ねたかった。私の懸念は合理的ですか、それとも非常に根本的なものを見逃していますか？

編集：例を挙げます。task1（10ミリ秒）とtask2（20ミリ秒）があります。彼らは同時に別々の2つのスレッドで開始しました。私の主張（これも心配ですが、よくわかりません）は、task1がtask2と処理能力を共有しているため、10ms以上かかることです。

RTOSのタスクが自動的に決定論的であるとは限りませんが、タスクを実行するタイミングと頻度に、より厳しい制約を課すことが可能です。RTOSは通常、タスクに厳しい優先順位を提供します。いつでも、優先度が最も高い準備完了タスクが実行されています。コードの作成者は、実行しているタスクのセットを完全に制御することもできます。あなたがそれらを書かない限り、例えば、ディスクにデータをスワップするためにあなたのコードを中断するかもしれない高い優先度のバックグラウンドタスクがないと合理的に期待できます。

これに加えて、一部のRTOSは協調マルチタスクを提供します。プリエンプティブマルチタスクとは対照的に、協調マルチタスクでは、タスクは、自発的にCPUの制御を放棄するまで実行を続けます。

RTOSに関する限り（組み込みシステム上）、マルチスレッドアプリケーションを作成すると、同時に実行されているスレッドの数に応じて、同じことが起こると思います。

いいえ！

それが起こった場合、それはリアルタイムOS（RTOS）ではありません。

簡単に言えば、RTOSの定義はマルチタスクや優先度とは関係がないということです。すべてのタスクがタイミングを保証しているだけです。

RTOSの特性と見なされる残りの部分（優先順位付け、タスク完了など）は、指定された時間間隔内にタスクを完了する必要があるシステムを構築した結果（または機能）にすぎません。

複雑なエッジケースの多くは基本的に許可されていないため、RTOSでのマルチタスクは、ソフトタイムOSよりも概念的に単純です。

RTOSは通常、スループットを保証しませんが、代わりにレイテンシを保証できます。

これは通常、以下のFreeRTOSなどの優先システムによって実現されます。

FreeRTOSスケジューラーは、ReadyまたはRunning状態のタスクに、ready状態にある優先順位の低いタスクよりも常にプロセッサー（CPU）時間を優先させるようにします。つまり、実行中の状態に置かれたタスクは、常に実行可能な最も優先度の高いタスクです。

イベントの処理に10ミリ秒かかる優先度1のタスク、別のイベントの処理に100ミリ秒かかる優先度2のタスク、およびバックグラウンドの優先度3のタスクがあるとします。1秒ごとに1つの優先度1のイベントを取得することを期待している場合、優先度2のイベントを処理する最悪のケースは10ミリ秒+ 100ミリ秒であると言えます。優先度3のタスクは、イベントによって任意にスローダウンされる可能性がありますが、優先度が低いため、気にする必要はありません。

コメントにしたいのですが、文字数が多すぎます。とにかく、ozgurがコメントレスポンスの質問で判断すると、私のスレッドの実行にこれほど長い時間がかかるとは言えず、OSのおかげで他のスレッドと魔法のように連動すると期待できないという点が欠けているようです。スレッドを設計し、最悪の場合のパフォーマンスについてそれらを分析する必要があります。最悪のケースが要件を満たさない場合は、スレッドを再設計する必要があります。

したがって、スレッド1が完了するまでに10ミリ秒かかり、スレッド2が20ミリ秒かかると言うのではなく、スレッド1は15ミリ秒ごとに実行する必要があるとも言う必要があります。スレッド2は40ミリ秒ごとに実行する必要があります。スレッド3は500ミリ秒ごとに実行する必要があり、スレッドNは1500ミリ秒ごとに実行する必要があります。次に、最悪のシナリオで各スレッドが完了するまでにかかる時間に時間を割り当てます。これらすべてを組み合わせて、考えられる最悪のシナリオを特定し、すべてのスレッドがそのタイミング要件を満たしていることを確認する必要があります。この分析では、タイミング要件を満たすために、一部のスレッドを他のスレッドよりも高い優先度にする必要があるかどうかを特定します。

たとえば、スレッド5が実行されている場合、スレッド4によって中断されます。スレッド4はスレッド3によって中断され、スレッド3はスレッドNによって中断されますが、これは最悪の場合のシナリオです。これらすべてをタイムラインに配置し、この最悪のシナリオでも、すべてのスレッドがそのタイミング要件を満たしていることを確認します。リアルタイムOSでスケジューラと優先度を使用することにより、スレッドがこのワーストケースのシナリオを確定的に完了するようにすることができます。その決定論は、リアルタイムOSを作るものです。

スレッドを同じ優先度にすると、スケジューラーは次に実行するスレッドを自由に選択できるため、その決定論の一部（すべてではないにしても）が失われます。

WindowsのようなOSでは、各スレッドがいつ実行されるかを指定できないだけでなく、アプリケーションがいつでも実行されることを保証することもできません。OSはアプリケーションを停止し、必要に応じてバックグラウンドサービスを実行する可能性があります。つまり、決定論はありません。したがって、WindowsはリアルタイムOSではありません。ただし、（thread1が10秒ごとに実行され、thread2が15秒ごとに実行される）のようにタイミング要件が大きい場合は、スロップを考慮している限り、Windowsを本質的にリアルタイムOSのように扱うことができます。 （与えるか、数百ミリ秒かかり、ときどきウィンドウが失われる）で十分です。

「現実の世界」ではシナリオは不可能であると他の回答が述べていますが、あなたの質問に答えられるようにするには、架空のシステムを構築する必要があります。

私たちのシステムは、安定した速度でボールを発射する銃と、ボールを「キャッチ」し、各ボールをキャッチして1ステップ進む2つのボックスで構成されています。銃はいずれかのボックスで発砲するように切り替えることができますが、切り替えるたびに1つのボールが失われます。最初のボックスはその終わりに到達するために1000ステップ（ボール）を必要とし、ボックス2は2000を必要とします。

シナリオ1（次々とタスク）：
-銃はボックス1で1000ボールを発射し、スイッチ（コスト1ボール）とボックス2で2000ボールを発射し、合計3001ボールを発射します。

シナリオ2（タスク「同時」）：
-銃が1つのボックスで5つのボールを発射し、他のボックスで5つのボールを切り替えて発射して、同時性の外観を与えます。切り替えコストは（1000/5 x 2 =）400ボールです。したがって、2400個のボールを撃った後、ボックス1は最後に到達し、ボックス2は最後に到達するためにさらに1000個のボールを必要とし、合計で3400個のボールになります。

これらの結果をシナリオに適用すると、タスク1とタスク2の前半は24ミリ秒後に完了し、タスク2の後半はさらに10ミリ秒で完了し、合計34ミリ秒になります。これは、タスクの切り替えに時間がかかるため、タスクの完了に必要な時間が増加することを明確に示しています。これらの結果は、タスク1が完了するまでに12ミリ秒、タスク2が22ミリ秒かかるのと同じです。