Fiberもどきの「Protothreads」は既存RTOSとの組み合わせで力を発揮する：リアルタイムOS列伝（43）（1/3 ページ）
IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第43回は、実装がFiberの一種のようになっている「Protothreads」を取り上げる。
今回ご紹介するリアルタイムOS（RTOS）の「Protothreads」、作者はスウェーデンのAdam Dunkels氏である。実はDunkels氏の名前は連載第16回の「Contiki／Contiki-NG」でも出て来ている。このときはサラッと流してしまったProtothreadsをご紹介しようと思う。
そもそもFiberとは何か
Protothreads、連載第16回では「実装を見ているとFiberの一種ではないかと思う」と書いたが、今もその印象は変わっていない。Fiberというのは、あまり流行っていないというか、一応RubyにはFiber Classが用意されているから使えなくはないし、OSでこれをサポートしたものもある（最初に見たのは確か「Solaris 2.0」か何かの時だったと思うのだが、今調べても見当たらないので別のOSだったのかもしれない）はずだが、まぁ知名度は高くない。
Fiberを簡単に言えば「軽量なThread」である。Process／Thread／Fiberの違いを簡単にまとめると、以下の表1のようになる。
| メモリ空間 | Task Schedule | |
|---|---|---|
| Process | Processごとに独立 | Preemptive |
| Thread | 親Processの空間を共用 | Preemptive |
| Fiber | 親Threadの空間を共用 | Non-Preemptive |
| 表1 Process／Thread／Fiberの違い | ||
Processは一番独立性が高い一方、ProcessごとにPCB（Process Control Block）を必要とするし、利用するメモリ空間も別に必要になるから、特にRTOS向けでは負荷が大きい。Threadはその親Processのメモリ空間やPCBを共用しながら、処理の流れだけを親Processとは別にハンドリングできるので、相対的に負荷が軽い（ただし同じ親Process配下のThread間でのメモリ保護は当然ない）。Threadの制御も原則Preemptive、つまりOSのスケジューラーが行う（「原則」というのは、たまにここから外れる実装があるから）。
ではFiberは？ というと、Threadをさらに細分化した格好であり、親Thread（＝親Process）のメモリ空間とPCBを継承するし、親Threadの制御の管理下にあるからFiber全体はPreemptiveで動作する格好だ。異なるのは、Fiber同士の制御であり、ここはNon-Preemptiveである。つまり、Fiberの制御はプログラマーに任されているわけだ。
こういう特徴だから、実はFiberの実装はそう難しくない。少なくともOS側で用意すべきものはそう多くないし、後付けの形でFiberを実装させることもできる。今回ご紹介するProtothreadsはまさしくそういう類のもので、もっと言えば厳密にはFiberではなく「Fiberもどき」であり、これがRTOSか？ といわれるとちょっと悩むところはある。ただ、Wikipediaの“Comparison of real-time operating systems”には堂々とProtothreadsの名前がRTOSの一つとして出ているし、開発者のDunkels氏も“Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems”という論文を出していたりするので、まぁRTOSの延長の一つとして今回は取り上げてみた。
さて、Protothreadsの開発動機であるが、Memory-Constrained Networked Embedded Device（メモリ容量に制限があるネットワーク接続可能な組み込みデバイス）にマルチタスクを実装すると、どうしてもメモリを浪費する傾向があることが問題であるとする（図2）。
Copyright © ITmedia, Inc. All Rights Reserved.