　今回ご紹介するリアルタイムOS（RTOS）の「Protothreads」、作者はスウェーデンのAdam Dunkels氏である。実はDunkels氏の名前は連載第16回の「Contiki／Contiki-NG」でも出て来ている。このときはサラッと流してしまったProtothreadsをご紹介しようと思う。

図1　「Protothreads」のWebサイト［クリックでWebサイトへ移動］

⇒連載記事「リアルタイムOS列伝」バックナンバー

そもそも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）。