RTOS について聞いたことがありますが、良いことばかりです。たとえば、優先順位の逆転を回避するためにプログラマがスケジューラをより細かく制御できるようになり、タイミングがより一貫し、マルチタスキングが向上します。しかし、すべての標準的なデスクトップ セットアップでは、リアルタイムではない OS が使用されています。では、RTOS の使用にはいくつかのトレードオフがあるに違いありません。
4 に答える
RTOS は通常、予測可能性と扱いやすさのために、スループットのパフォーマンスと機能をトレードオフします。人々が適用する「リアルタイム」の通常の定義は「決定論的」です。お金を払わずに決定論を持つことはできません。
汎用 OS では、「一般的なケース」の動作が動機になります。つまり、平均的なパフォーマンスが非常に高く、柔軟性が高いことを望んでいます。RTOS では、「最悪のケース」の動作に対する信頼できる上限が必要であり、スループットまたは一般的なケースの動作に (多くの場合、多額の) 代償を払います。
はい、Windows や Linux リアルタイム スレッドなどのハイブリッドを作成することは可能です。しかし、最終的に利用可能なリソースのセット (CPU、IO 帯域幅など) は有限であり、コンシューマ OS と RTOS はさまざまな基準に基づいて最適化するため、どこかでペナルティを支払うのが一般的です。一部の RT Linux アプローチでは、パーティションを作成することで、これを明示的に処理しています。パーティションごとに、異なる仮定と異なる最適化基準が最適化されます。
どのような機能が取引されますか? 正確なリストを提供することはできませんが、汎用 OS には無数のドライバーがあり、新しいデバイスの変化に追いつくことができる傾向があります。RTOS は、適時性が十分に理解されているか、他のアクティビティに干渉しないように明示的に保持できる、はるかに小さなセットに焦点を当てる傾向があります。通常、それらを実装することは合理的ではないため、通常の RTOS ではおそらく同じドライバーを選択することはできません。
スループット"リアルタイム" != "リアルタイム" を覚えておいてください。システムがリアルタイムであるということは、アクティビティの完了時間が正確さの一部であることを意味します。場合によっては、これは多くのアクティビティを非常に迅速に処理することを意味します (高スループット)。他の場合は、比較的遅いが非常に予測可能な期間で処理されている可能性があります。RTOS の構造はスループットが高い場合がありますが、通常、同等の RTOS のスループットを達成することはできません。これは、そのスループットを公正に達成するために使用される手法 (キャッシング、高度な対話型スケジューリング アプローチ、「公平な」キューイング、およびロック競合) が有効ではないためです。単一のタスクの適時性の予測可能性に反します。
これが大きな理由かどうかはわかりませんが、プロセッサにシステム管理モードのような非リアルタイム機能が存在することは、リアルタイム OS を実際には許可しないと思います。 OS が SMI に応答したい場合、OS ができる最善の方法は、タイムアウトして、制御を取り戻したときにクラッシュすることです (制御をタイムリーに取り戻した場合)。そのため、BIOS もリアルタイムである必要があります。これは、Microsoft のような 1 つの企業だけが OS をリアルタイムにするのと同じくらい簡単ではありません (それ自体は簡単ではありません)。
とにかく、平均的なユーザーにとっては、おそらくそれほど多くの利益はないでしょう.
デスクトップ アプリケーションの開発に役立つ機能は、リアルタイム OS を必要とするアプリケーションでは重要ではありません。そのため、RTOS ベンダーは、高速ブートやエラー回復など、顧客にとって重要なことにエンジニアリング時間を集中させる傾向があります。
迅速なアプリケーション開発とリアルタイムが重複する市場が生まれるまでは、OS ベンダーがそのリソースを両方に分割することはまずありません。迅速な開発とセーフティ クリティカルは両立しません。
Blackberry Playbook が QNX に移行することで、RTOS 向けのフレンドリーな開発環境 (ライブラリとツール) が初めて見られるかもしれません。
基本的には「なぜ誰もが C で webapps を書かないのか?」と同じ理由です。はるかに高速ですが、はるかに困難です。大規模なシステムでの RTOS は、多くの制御がアプリケーション プログラマに与えられるため、扱いにくくなります。