図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サービスを使用することによって生じ得る影響を理解しておく必要があります。