マイクロソフトが買収した「ThreadX」あらため「Azure RTOS」はまだ実体がない：リアルタイムOS列伝（4）（1/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第3回は、マイクロソフトが2019年4月に買収し、名称を「Azure RTOS」に変更した「ThreadX」を取り上げる。

[大原雄介，MONOist]

　広く利用されているリアルタイムOS（RTOS）の1つである「ThreadX」については、以前にTechFactoryの記事で解説したことがある。現在、メンター・グラフィックス（Mentor Graphics）から販売されている「Nucleus RTOS」の原型となった「Nucleus RTX/Nucleus Plus」の作者であるビル・ラミー（Bill (William) Lamie）氏が、そのNucleus RTX/Nucleus Plusの販売元だったAccelerated Technologyを離れて、次に作ったのがExpressLogicという会社と、このThreadXというRTOSである。

　このExpressLogicを2019年4月に買収したのがマイクロソフト（Microsoft）である。そして同年10月には、ThreadXを「Azure RTOS」という名称で提供することを発表している。そんなわけで、現状の製品名はAzure RTOSになるわけだが、その現状の話は最後にするとして、取りあえずはThreadXについて紹介したいと思う。

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

図1　ExpressLogicのWebサイト。アクセスすると、最初に“Azure RTOS is now available from Microsoft”という案内が表示される（クリックでWebサイトへ）

ピコカーネルアーキテクチャにより2KBでも動作可能

　ThreadXそのものは、独自の「picokernel architecture（ピコカーネルアーキテクチャ）」で構成されるRTOSである。いわゆるマイクロカーネルの場合、カーネルのコアと追加のサービスの間にLayer（レイヤー）を設けるのが一般的で、このためサービスを使う場合はLayerをまたいでの呼び出しになる。対してpicokernelの場合、このLayerが存在せず、サービスは直接カーネルのコアに追加する形になるので、マイクロカーネルで必要なサービスの呼び出しのオーバーヘッドなどが最小化できる、としている。ちなみに最小構成だと2KB、通常の環境でも15KB程度のフットプリントで動作可能という話だ。

　カーネル周りの特徴として挙げられている項目は、以下のようになる。

• Automatic scaling
• Deterministic processing
• Fast real-time performance
• Preemptive and cooperative scheduling
• Flexible thread priority support（32〜1024）
• Dynamic system object creation
• Unlimited number of system objects
• Optimized interrupt handling
• Preemption-threshold
• Priority inheritance
• Event chaining
• Fast software timers
• Run-time memory management
• Run-time performance monitoring
• Run-time stack analysis
• Built-in system trace

　RTOSでは割とポピュラーな項目であるが、これらの中でちょっと目を引くのが「Event chaining」だろう。これは、イベントに対するCallback関数を登録できるという仕組みである。あるスレッドが1つのイベントを待っているだけなら難しくないが、複数イベントをうまくハンドリングするのは難しい（あるイベントの処理中に別のイベントが発生する場合もあるため）。そこで必要なら、ISR（Interrupt Service Routine：割り込みサービスルーティン）でいろいろと細工することになりがちだが、当然難易度が上がってしまう。ThreadXの場合、イベントのCallbackの側で処理を記述すれば良く、イベントそのもののハンドリングはカーネル側で行ってくれるので、このあたりの記述がかなり楽になる。

図2　アドレスなどはあくまでも一例で、当然このあたりはコンフィギュレーションで設定可能である（クリックで拡大）

　Event chainingは、Queue、Semaphore、Event Flagに対して設定が可能であり、ThreadXで提供されるSystem Objectはほぼこのどれかを使ってアプリケーションに通知を行っている。結果的に、ほとんどのSystem Objectに対してこのEvent chainingが利用可能になるというわけだ。

　ThreadXのメモリモデルは、基本的にはMCUに向けたStatic（静的）な構成（図2）で、当然仮想記憶などには未対応である。ただしこれとは別に、「Block Memory」と「Byte Memory」という2種類のDynamic（動的）なメモリ管理機構を提供している。Byte Memoryの方は、いわゆるC言語のmallocやfreeに対応する、任意のサイズのメモリプールを提供するもので、対してBlock Memoryの方は固定サイズのメモリプールを提供する機能になっている（このメリットについては、メモリフラグメンテーションが避けられる、としている）。

　なお、メモリ保護については、MCUの持つMPU（Memory Protection Unit）をサポートして、これに準ずる形での利用が可能である。