実行時にRTOSオブジェクトを削除しないでください!

RTOSは多くの機能をアプリケーションに提供します。最も重要な機能はタスク管理ですが、タスクとISRを共存させる機能も備えています。このタスクとISRの共存は、使用するRTOSに応じて、タスクとISRによるセマフォとイベントフラグを使った他のタスクへの信号送信、相互排除セマフォを介したリソース管理、およびメッセージキューを利用したメッセージ送信などを可能にすることによって行われます。これらのサービスは、図1に示すRTOSオブジェクトと呼ばれるデータ構造に作用するAPIによって実行されます。図1では少しわかりにくいですが 、タスクは常にタスク制御ブロック(TCB)によって定義されるので、実際はRTOSオブジェクトでもあります。

図1. RTOSオブジェクト

 

一部のRTOSでは、ユーザがRTOSオブジェクト用にストレージを割り当てる必要があり、さらにアプリケーションがそれらのオブジェクトを操作することがないように、RTOS APIを通じてオブジェクトを初期化(「作成」ともいう)しなければなりません。また別のRTOSでは、RTOS自身がAPIを通じてストレージの割り当てとRTOSオブジェクトの初期化を行います。どちらの方法にも長所と短所がありますが、それについてはここでは触れません。たとえば、uC/OS-IIIセマフォサービスを使用するには、以下のようなコードを記述する必要があります。

OS_SEM  MySem;             // Allocate storage for a semaphore


    :                      // Somewhere in your code …
    :
OSSemCreate(&MySem, …);    // Create (i.e. initialize) the semaphore
    :
    :

RTOSオブジェクトに作用するRTOSサービスを呼出し可能とするには、そのサービスの如何を問わず、あらかじめすべてのRTOSオブジェクトを作成しておく必要があります

ユーザーアプリケーションでセマフォ(RTOSオブジェクト)をどのように使用するかを図2に示します。図に示すように、タスクもISRもセマフォ信号を送ることはできますが、この信号が送られてくるのを待つことができるのはタスクだけです。この例では、目的の異なる2つのセマフォを示しています。

図2. セマフォの使用


ほとんどのRTOSでは、RTOSオブジェクトは削除できるようになっています。オブジェクトを削除するということは、単にそのオブジェクトの初期化を解除することで、場合によってはそのストレージを解放することを意味します。アプリケーションコードに関して言えば、そのRTOSオブジェクトを二度と使用しない、あるいは参照しないということです。しかし、RTOSオブジェクトを削除するサービスがあっても、削除は行わないことを強く推奨します。実際、セーフティクリティカルシステムとして認証を得るためには、数ある条件の1つとして、一度作成したオブジェクトは削除できないようになっていることが挙げられています。

「では、なぜRTOSの開発者はこのようなAPIを提供するのか?」という疑問が生じます。これにはいくつかの理由があります。

その1つは一貫性です。オブジェクトを作成できるのなら、削除もできて当然です。実際、システムを起動するためだけにアプリケーションがタスクを作成する場合もあります。いったん起動してしまえばそのタスクはもはや不要であり、通常はタスクが自分自身を削除します。しかし筆者としては、一般にこのようなタスクは残しておき、システムのモニタリングやアプリケーション内の他の用途で使用することを推奨します。RTOSオブジェクトの作成と削除は、特にタスクに関する限り高くつくことが多いのですが(CPUサイクル)、スタートアップタスクの場合、そのオーバーヘッドの影響はほとんどありません。

システムがメモリ保護ユニット(MPU)を使用しており、そのMPUがスタックオーバーフローかアクセス違反を検出した場合は、サブシステムの一部をダウンさせるかシステム全体をダウンさせる以外に選択肢はありません。このような場合、ユーザがRTOSオブジェクトを削除して再起動できるかどうかは、その障害を引き起こした原因とそれらのシステムが再起動可能かどうかによって決まります。たとえば、ユーザインタフェースや通信などのサポート機能は再起動可能な場合がありますが、障害が制御システム内で発生したものである場合は、リセットのような思い切った方法は避け、制御されたシャットダウンを行う以外に選択肢はないでしょう。この場合、ISR、タスク、I/Oなどは安全な状態に置かれます。シャットダウンシーケンスでは、設備の損傷を招かないよう、また人員の負傷を避けるためにも、RTOSオブジェクトは慎重に設計された順番で削除されます。

他のあらゆるケースと同様に、RTOSサービスの使用に際しては、RTOSオブジェクトを削除する場合を含め、RTOSサービスを使用することによって生じ得る影響を理解しておく必要があります。

著者について

本稿は、RTOSを使用したアプリケーション開発をテーマとしたシリーズの一部です。

Jean Labrosse(ジーン・ラブロス)氏は、Micriumの創設者であり、広く普及しているuC/OS-IIおよびuC/OS-IIIカーネルの作成者です。組込みソフトウェアのuC/ラインの発展のために積極的に取り組んでいます。

組込みシステム市場での豊富な経験を有し、市場を知り尽くしているLabrosse氏は、Weston Embedded Solutionsの主席アドバイザおよびコンサルタントとして、現行のRTOS製品の将来的な方向性の策定に尽力しています。Weston Embedded Solutionsは、Micriumのコードベースから生まれた信頼性の高いCesium RTOSファミリー製品のサポートと開発を専門としています。

連絡先: [email protected].

jean_labrosse.jpg

申し訳ございませんが、弊社サイトではInternet Explorerをサポートしていません。サイトをより快適にご利用いただくために、Chrome、Edge、Firefoxなどの最新ブラウザをお使いいただきますようお願いいたします。