センサーノード向けに振り切りまくったRTOS「Contiki」が「Contiki-NG」へ進化：リアルタイムOS列伝（16）（2/4 ページ）

[大原雄介，MONOist]

通常のRTOSからは懸け離れている

　もっとも、普通に作ったら、こんなサイズでOSが実装できるわけがない。Contikiの場合、プログラムは全てLoadable ModuleとしてダイナミックにLoad／Unloadされるのだが、その構図はいわゆるOSというよりは、ほとんど「CP/M」や「MS-DOS」のように、メモリ中には最低限のHookだけ残る格好で実装されているように見える（図4）。

図4　これだけ見ると、ちゃんとカーネルスケジューラーが残りそうに見えるが、図3のRAMの利用量を見ると、カーネルスケジューラーすらも外部に追い出しているとしか思えない［クリックで拡大］

　この方式、確かにメモリ占有量は極小になるが、例えば割り込みが入った場合に、OSでこれをハンドリングしようとすると猛烈に時間がかかることになる。その意味では、通常のRTOSからはちょっと懸け離れている。

　マルチタスクの方式も変わっている。一般的にはイベントドリブン（つまり割り込みが入ったらISRからそのハンドラを呼び出す形でユーザーアプリケーションを起動、作業が終わったらまたイベント待ちに戻る）とマルチスレッド（複数のThreadが見かけ上は完全に同時に動作する：スケジューリングはTimerなどを組み合わせたRound Robinか、もしくはPriorityベース）があるが、これを組み合わせた形になっている（図5、6）。

図5　“Multi-threading implemented as a library”ということは、要するにアプリケーション側にThread制御を引き渡すことを意味している［クリックで拡大］

図6　基本はThread（というかメインとなるProcess）が1個だけ走り、このProcess内部がマルチスレッド（もどき）で実行される、という形になる。2つ目のThreadは基本的には走らない格好［クリックで拡大］

　ここでカーネルそのものはイベントドリブンだが、ユーザーアプリケーションはマルチスレッドである。問題はこのマルチスレッドが、本当の意味でのマルチスレッドではなく、最初に少し紹介したProtothreadsを利用していることだ。Protothreadsでは、複数のThreadの制御はアプリケーション側で行う（つまりカーネルは介在しない）形になる。このためContikiでは、見かけ上はマルチスレッドに見えるが、そこで動くプログラムとしては1つであり、いわゆる一般的な意味でのマルチスレッドには対応していない（正確に言えば対応はしているが、カーネルはThread制御で「何もしない」）ということになる。“Threads only used if explicitly needed”というあたりは、要するに「やるな」と言ってるわけだ。