RTOSベース設計におけるリソースの共有

著者：Jean J. Labrosse氏、RTOSエキスパート

RTOSは各タスクに対してCPUを占有しているかのように思わせていますが、多くの場合、複数のタスクが変数、表、データ構造、I/Oデバイスなどのリソースを共有して処理を実行しています。プリエンプションの可能性があるため、タスクに対して、共有リソースへの排他的アクセス権を与える必要があります。

通常、RTOSは、割込みのイネーブル／ディスエーブル、スケジューラによるタスク切替えの防止（スケジューラのロック／アンロック）、セマフォ、ミューテックスなど、排他制御を実現するために多くのサービスを提供します。実際にどの仕組みを使用するかは、状況によって異なります。

もし、アプリケーションが単純な変数にアクセスしようとしており、それがわずかなCPUクロックサイクルで実行できる場合は、割込みをディスエーブルして変数にアクセスした後、再度、割込みをイネーブルするのが最も望ましいと言えるでしょう。

一方、リソースにアクセスするのに数千ものCPUサイクルを必要とする場合は、ミューテックスを使用するのが最良のやり方です。ミューテックスを使用することで、1960年代初期にEdsger Dijkstra氏によって定義された（通常の）セマフォを使用した際に起こり得る無制限の優先順位の逆転という問題を回避することができます。

次のコードスニペットで、ミューテックスの仕組みを説明します。

ここで注意すべきことは、ミューテックスは使用する前に作成（つまり初期化）しておく必要がある点です。この処理はすべてのRTOSで行うことができるので、現在使用中のRTOSあるいは採用予定のRTOSのマニュアルを参照してください。

あるタスクが別のタスクの所有するリソースにアクセスする必要が生じた場合、デッドロックが発生します。すべてのタスクが必要なすべてのリソースに同じ順序でアクセスし、その逆の順序で解放することに同意していれば、デッドロックは回避できます。

次のコードスニペットでは、複数のリソースが適切にアクセスされています。どちらのミューテックスも作成済みであれば、リソースAとリソースBに任意の順序でアクセスできます。

また、タイムアウト機構のあるRTOSでも、デッドロックの回避が可能です。つまり、タイムアウトによって、タスクがリソースの解放を永遠に待ち続ける状況を回避することができます。

ただし、タイムアウトによって「Get()」から戻るということは、タスクにはそのリソースのアクセス権がないことを意味し、コードはその状況に応じた処理を行う必要があります。つまり、排他的アクセス権がなくなったため、そのリソースにアクセスすることはできません。

リソースの競合は、サーバタスクを作成することで回避できます。サーバタスクは常にリソースを保有しており、クライアントタスクはサーバに対してサービスを要求します。

たとえば、以下に示すように、タスク（サーバ）は現在の時刻（年月日、曜日を含む）の追跡を担っており、クライアントクラウドは、サーバタスクの開発者が提供するAPIを通じて、サーバに対して以下を要求します。

• 現在の日付と時刻をASCII文字列で返（Clk_GetDateTimeASCII()）
• 時刻を変更する（Clk_SetTime()）
• 日付を変更する（Clk_SetDate()）
• その他

APIがリクエストを待ち行列に置くと、サーバは順番にそのリクエストに応じます。この例では、クロックタスクが常にクロック変数への排他的アクセス権を持っているため、これらの変数を他のタスクやISRと共有する必要はありません。

この方式により、共有リソースに関する多くの問題を回避することができます。

さらに詳しい情報

オンデマンドの英語ウェビナー「Benefits of multitasking your embedded application with an RTOS」および「Tips and hints for better debugging your RTOS-based application」もご参照ください。