センサーノード向けに振り切りまくったRTOS「Contiki」が「Contiki-NG」へ進化:リアルタイムOS列伝(16)(2/4 ページ)
IoT(モノのインターネット)市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS(RTOS)について解説する本連載。第16回は、センサーノード向けにいろいろと振り切りまくったRTOS「Contiki」とその進化版「Contiki-NG」を紹介する。
通常のRTOSからは懸け離れている
もっとも、普通に作ったら、こんなサイズでOSが実装できるわけがない。Contikiの場合、プログラムは全てLoadable ModuleとしてダイナミックにLoad/Unloadされるのだが、その構図はいわゆるOSというよりは、ほとんど「CP/M」や「MS-DOS」のように、メモリ中には最低限のHookだけ残る格好で実装されているように見える(図4)。
この方式、確かにメモリ占有量は極小になるが、例えば割り込みが入った場合に、OSでこれをハンドリングしようとすると猛烈に時間がかかることになる。その意味では、通常のRTOSからはちょっと懸け離れている。
マルチタスクの方式も変わっている。一般的にはイベントドリブン(つまり割り込みが入ったらISRからそのハンドラを呼び出す形でユーザーアプリケーションを起動、作業が終わったらまたイベント待ちに戻る)とマルチスレッド(複数のThreadが見かけ上は完全に同時に動作する:スケジューリングはTimerなどを組み合わせたRound Robinか、もしくはPriorityベース)があるが、これを組み合わせた形になっている(図5、6)。
図6 基本はThread(というかメインとなるProcess)が1個だけ走り、このProcess内部がマルチスレッド(もどき)で実行される、という形になる。2つ目のThreadは基本的には走らない格好[クリックで拡大]
ここでカーネルそのものはイベントドリブンだが、ユーザーアプリケーションはマルチスレッドである。問題はこのマルチスレッドが、本当の意味でのマルチスレッドではなく、最初に少し紹介したProtothreadsを利用していることだ。Protothreadsでは、複数のThreadの制御はアプリケーション側で行う(つまりカーネルは介在しない)形になる。このためContikiでは、見かけ上はマルチスレッドに見えるが、そこで動くプログラムとしては1つであり、いわゆる一般的な意味でのマルチスレッドには対応していない(正確に言えば対応はしているが、カーネルはThread制御で「何もしない」)ということになる。“Threads only used if explicitly needed”というあたりは、要するに「やるな」と言ってるわけだ。
Copyright © ITmedia, Inc. All Rights Reserved.