　タスクのそれぞれは、割り込みの場合と同様に優先度を持っており、優先度の高いタスクに対する処理トリガーが発生したら、優先度の低いタスクの実行を止めて、優先度の高いタスクの実行を開始する（これをプリエンプト動作（preemption）と呼びます）、それが終わったら優先度の低いタスクの実行を再開する、という切り替え動作が可能です（優先度に基づくイベントドリブンな処理実行動作）^※4）。

　さて、単一のCPUコアで、さまざまな処理を優先度に基づきイベントドリブン方式で実行しようとすれば、共有している演算用資源のうち状態を持つもの（コンテキスト（context）：汎用レジスタやステータスレジスタ、SP、FPUレジスタ内容など）を「お互いに壊し合う」という問題に対処しなければなりません。スケジューラ方式とRTOSのどちらを使用するのであれ必要になることですし、プログラミング言語として何を使用するのであれ、アセンブラレベルでは等しく必要になることです。

　「互いに壊し合う」という問題への対処のため、スケジューラ方式では一般に、割り込み処理（他の処理に対して「割り込む側」）であるということをコンパイラに指示することで^※5）、Cコンパイラに、割り込み動作時の「割り込まれる側」のコンテキストのスタックへの退避と、「割り込む側」の処理の終了時の「割り込まれる側」のコンテキストのスタックからの復帰のコード（C言語コードには表れない、アセンブラレベルで埋め込まれるコード）を出力させます。これに対してRTOSでは、あるタスクが他のタスクをプリエンプトする際に、RTOS自身でコンテキスト退避と復帰する処理を行うことで、退避、復帰を実現しています。この退避、復帰を伴う、実行対象処理の切り替え動作は、コンテキスト切り替え（context switch）と呼ばれます。

　コンテキストをスタックに退避することによって、高優先処理中に演算用資源が使用されコンテキスト内容が書き換えられたとしても、低優先タスクの動作の再開時には、再びスタックからコンテキスト内容を復帰し、何事もなかったかのように処理を再開することができます^※6）。

※3）細かいことを言うと、スケジューラ方式での割り込み処理でハードウェアとソフトウェアが行っていることと、RTOSでISRが行うことは完全には同じではありません（RTOSの場合、ISRからのreturn後に、次にCPU使用権を得るタスク選択をやり直すなどのRTOS内部動作が、割り込み処理から抜ける前に入るなど）。

※4）優先度に基づくイベントドリブン方式は、「今すぐやる必要がないなら、今すぐやる必要のある処理にCPUを明け渡す」のが基本です。急いでやらなければならないもの（デッドライン（deadline）がより短いもの）は、そうでないものよりも優先度を高くする、という使い方になります。

※5）Cコンパイラの実装にもよりますが、#pragma指令や__interruptキーワードを用いて「割り込む側」であることを示します。

※6）ただし、いつの間にか絶対時間だけは経過していたように見えますが……（マルチタスクOSやハイパーバイザーを導入すると、絶対時間の進みと、CPU割り当て時間の進みの2つを分けて考慮しなければならなくなる場面が出てくることがあります）。

　なお、「RTOSは重い」という言葉だけが独り歩きしてしまっているようで、RTOS導入で生じるオーバーヘッドを気にしておいでの方は少なくありません。しかし、「幽霊の正体見たり枯れ尾花」の気もなきにしもあらずで、コンテキスト切り替え動作の中身を把握すれば、オーバーヘッドの程度もおおよそ見当がつくようになるかと思いますし、よほど性能の限界ギリギリ（余裕なし）で利用しておいでの場合を除けば、問題にならないことも少なくありません。今後のソフトウェアのセキュリティ対応や機能追加のためのアップデートのために、よりいっそう、余裕を残しておくことが求められるようになるでしょうから、見方を改め、「重い」と言っているだけではなく、真剣に対処を検討してみるべきでしょう。

　また、ここでは解説を省略しますが、メモリ保護やタイミング保護を使用する場合、コンテキスト退避・復帰時にRTOSがMPU（メモリ保護ユニット）設定の切り替えや時間経過情報の退避・復帰も併せて行います（当然、オーバーヘッドは増えます）。

AUTOSAR RTEを使用する場合

前のページへ 1|2|3|4|5 次のページへ