3

カーネル空間で実行している場合、プロセスをプリエンプトできないことを理解しています。それが本当なら、RTOS ではどのように応答性が保証されますか (システム コールの実行に時間がかかる場合)? プロセスがカーネル空間で実行されている場合でも、プロセスのコンテキスト スイッチを実行できますか?

4

3 に答える 3

1

プロセスを横取りできるかどうかは、プロセス状態の設計に依存します。Linux では UNITERUPTIBLE_SLEEP があり、プロセスが要求した特定のサービスが完了したままスリープします。(例の読み取り) . サービスが完了せず、プ​​ロセスがシグナルを受信せず、無限にスリープしている (システム リソースを保持している) ということが起こる可能性があります。

RTOS の場合、リソース (メモリなど) が不足しているため、このアプローチは正当化されません。したがって、プロセスが UNITERUPTILBE STATE になることはありません。したがって、OSは、何らかのサービスをスリープ/待機しているプロセスに時期尚早にシグナルを送信できます。そのため、OS はプロセスをより細かく制御できるため、システム リソースも制御できます。

@Levente Kurusa が指摘したように、OS は一定の間隔を置いてプロセスにシグナルを送信し、OS に制御を渡す (適切な応答時間を保証するタイム スライス実行) か、サービスを待っていた場合は強制終了することができます。長い時間。

于 2013-08-29T06:35:38.293 に答える
1

RTOS では、各プロセスには最小実行時間があり、システム コールは文書化されており、最悪の場合、完了するまでにかかる最大時間が保証されるように実装されています。つまり、たとえば を呼び出す場合open()、RTOS のシステム コールのドキュメントには最悪の時間フィールドがあります。呼び出しが 100 ミリ秒以内に完了しない場合、呼び出しは失敗します。RTOS 向けのアプリケーション開発は、一般的な OS 向けの開発とはまったく異なります。各通話の時間などを考慮する必要があります。たとえば、QnX では、OS に最大応答時間を伝える必要があります。そのフレームでプロセスが完了しない場合、プロセスは終了します。
注: QnX は x86 用の RTOS です。

于 2013-08-27T08:39:25.500 に答える
0

RTOS アーキテクチャはかなり異なるため、一概には言えません。カーネル空間自体の概念は、その設計とそれが実行されるプラットフォームによっては、特定の RTOS に関連していない場合さえあります。たとえば、MMU のないターゲットは実際には概念を実装できませんが、一部のターゲットには、カーネルによって使用される可能性のある割り込みまたはスーパーバイザーの特権実行モードがありますが、それは同じことではなく、スタックとレジスタ セットの切り替えとアクセスのみが含まれます。管理メモリと I/O 空間ではなく、特定の命令に。

多くの RTOS は、タスク スケジューリング、タイマー、同期、および IPC のみを提供するカーネルをスケジューリングするだけであり、最終的なアプリケーションがモノリシックになるように、静的に好まれるライブラリとして提供されます。ほとんどの場合、すべてのスレッドが 1 つのメモリ空間を共有し、タスク モデルが実装されていないため、「軽量」スレッドではなく「プロセス」の概念が共有されます。「カーネル空間」の概念がある場合、通常は OS スケジューラ自体のみがそのモードで実行され、すべてのタスク、スレッド、またはプロセスはその「空間」の外で実行されます。

MMU を広範に使用し、「プロセス」モデルを使用する OS は QNX です。これは、マイクロカーネル アーキテクチャを使用するため、OS の大部分とすべてのユーザーが、スケジューリングを担当するシステムのごく一部のみが「カーネル空間」で実行されます。プロセスはその外で実行されます。

ただし、RTOS では例外なく、割り込みは無効にされないか、最小限の時間だけ無効にされ、スケジューラ自体は完全に決定論的です。

RTOS の概念をよりよく理解するには、Jack Ganssle によるこのオンライン コースをご覧ください。

于 2013-08-31T08:44:45.437 に答える