POSIXについて少し
QNXの新しいバージョンがリリースされるたびに（そして1981年にQNX RTOSの最初のバージョンが登場したことに注意する必要があります）、開発者は以前の経験を活用し、開発者にとってより便利なシステムを改善しました。 これが、QNX Neutrinoがスレッド管理、リアルタイム拡張、追加のリアルタイム拡張、アプリケーション環境プロファイル（AEP）などのPOSIX 1003.1標準をサポートする理由です。
なぜこれについて話しているのですか？ とても簡単です。 QNXの特徴であり、POSIXに関連する2つの点に注意したいと思います。 POSIXオペレーティングシステムはUNIXを隠すと考えられています。 もしそうなら、そのようなシステムは面倒であり、組み込みソリューションで使用することはできません。 ただし、QNXの場合、これは正しくありません。 POSIX標準では、実装ではなくインターフェイスについて説明しています。 これは、POSIXレイヤーの下に、マイクロカーネルを含むすべてのものを隠すことができることを意味します。
私が詳しく述べたい2番目の点は、おそらく明らかです。 これらはもちろん、POSIXがQNXで提供する利点です。
- コードの再利用。 あるPOSIXオペレーティングシステムのコードを開発、デバッグ、テストしたら、QNXを含む別のPOSIXシステムで再利用できます。
- プログラマーの「移植性」。 POSIXおよびUNIXに精通した開発者または開発チームは、リアルタイムの組み込みシステム（もちろんQNXを意味します）の開発を簡単に開始できます。 結局のところ、OSのほとんどは既に馴染みのあるものです。
真のコア
QNX RTOSは、マイクロカーネルアーキテクチャに基づいています。 停止する価値があると思います。次に進む前に、マイクロカーネルとは何かを判断します（少なくともQNXの用語では）。 小核という用語はしばらくの間非常に人気があり、小さなコアを含む多くのシステムは小核と呼ばれています。 そして、コアがさらに小さい場合、それはナノ核と呼ばれます。 これはQNXに完全に当てはまるわけではありません。 カーネルのサイズが小さいことが主な目標ではありません。 これは、オペレーティングシステムの多くの機能（たとえば、ファイルシステムサポートなどの使い慣れた機能を含む）が、カーネルからユーザーアプリケーションの領域に取り込まれるというものです。 また、マイクロカーネル自体が実行する機能はごくわずかであり、そのほとんどがタスク間相互作用を提供します。
- メッセージング（これは、マイクロカーネルが行う主なことです）;
- フロー管理。
- スケジューリング（フロー）;
- 同期（ストリーム）;
- 信号管理;
- タイマー管理。
上記にリストしたのは、QNXマイクロカーネルが行うことのすべてです。 ネットワークドライバーやディスクサポートのようなものは、通常のユーザープロセスのように実行および動作する別個のモジュールに配置されます。 （モノリシックコアをベースにしたシステムを超える）すべての利点を備えています。 そして、これらの利点は何ですか？ 非常にシンプル：
- 小核のソースコードは、モノリシックカーネルのソースコードよりもはるかに小さいため、カーネルのデバッグとテストが容易になります。
- マイクロカーネルによりモジュール性が向上します。 最終的なターゲットシステムは、要件に合わせて簡単に構成できます。 必要なマネージャーを立ち上げるだけで十分です。
- マイクロカーネルにより、システムの信頼性が向上します。 ドライバーでエラーが発生した場合、これはシステム（およびマイクロカーネル）の崩壊につながりません。また、システム全体を再起動することなく、ドライバー自体をいつでも再起動できます。
神話：QNXマイクロカーネルはアセンブラーで書かれています
一部の開発者の間では、QNX Neutrinoマイクロカーネルの高いパフォーマンスとコンパクトさは、アセンブリ言語で記述された結果であると考えられています。 しかし、これはそうではありません。 マイクロカーネルはほぼ完全にCで記述されています。パフォーマンスとコンパクトさは、十分に確立されたアルゴリズムと構造を使用した結果です。
QNXのプロセスとスレッド
POSIX仕様によると、QNX RTOSはストリームをサポートしています。 さらに、QNXマイクロカーネルはスレッドのみを制御し、最小の「実行単位」と見なすことができるのはスレッドです。 QNXの各プロセスには、1つ以上のスレッドを含めることができます。 このように、プロセスはスレッドのコンテナとして見ることができます。
最も単純な場合、プロセスには1つのスレッドを含めることができます（また、含める必要があります）。 ただし、場合によっては、1つのプロセスで複数のアルゴリズムを並列実行する必要があります。 QNXから小さな例を挙げます。 ファイルシステムマネージャーは、複数のクライアント（他のプロセス）からの要求を並行して受信および処理できます。 マネージャーが1つのスレッドで作業した場合、マネージャーに連絡する2番目のクライアントは、以前に要求された操作の完了を待つ必要があります。 幸いなことに、QNXのファイルシステムマネージャーは複数のスレッドで動作するため、複数のアプリケーションを同時に並行して処理できます。
QNXのすべてのプロセスは互いに分離され、独自の仮想アドレス空間で実行されます。 メモリ管理ユニット（MMU）は、このような保護の実装を担当します。 プロセッサ内のMMUデバイスの存在は、QNXを起動するための前提条件です。 同時に、1つのプロセスのスレッドは1つのアドレス空間で動作します。
システム内のすべてのタスクが同じアドレス空間で動作するフローである場合、スキームに従って実装されたシステムがあります。 一方では、これはプロセス間通信を容易にします。 しかし一方で、スレッドのエラーはシステム全体の崩壊につながる可能性があります。 そして、この原則に基づいて構築されたシステムのデバッグと保守は、はるかに困難です。
神話：QNXマイクロカーネルはプロセス間でコンテキストをゆっくり切り替えます
スレッドはもともと、UNIXシステムで、プロセス間のコンテキスト切り替えが遅すぎるという問題の解決策として登場しました。 最も可能性が高いのは、それ以来、プロセス間のコンテキスト切り替えが非常に遅いことが一般に受け入れられているためです。 また、マイクロカーネルを使用してメッセージを送信する場合、モノリシックカーネルを使用する場合よりも多くのコンテキストスイッチが実行されるため、簡単な結論が得られます-QNXは低速です。 ただし、QNX Neutrinoアーキテクチャは、コンテキストスイッチングのパフォーマンスの問題を解決します。 また、QNXでは、プロセスとスレッド間のコンテキスト切り替えの速度に実質的に違いはありません。
ストリームの生き方
プロセスの実行中に、プロセス内のスレッドを動的に作成および削除できます。 たとえば、スレッドを作成する場合、
pthread_create()
関数は必要なリソースを割り当てて初期化し、スレッドはプロセスのアドレス空間内の指定された関数から開始します。 スレッドが終了すると、たとえば
pthread_exit()
関数を使用して、リソースが解放されます。
スレッドの実行中は、準備完了（準備完了）またはブロック済み（ブロック済み）の2つの状態になります。 しかし、実際には、スレッドをブロックできるさまざまな理由があり、
pidin
（QNX固有のバージョンの
ps
ユーティリティ）を使用してプロセスとスレッドに関する情報を表示すると、SEND、RECEIVE、SIGWAITINFO、NANOSLEEPなどのさまざまな状態を観察できますその他。 たとえば、この状態では、USBマネージャースレッドがあります。
# pidin -P io-usb pid tid name prio STATE Blocked 4101 1 proc/boot/io-usb 10o SIGWAITINFO 4101 2 proc/boot/io-usb 21r RECEIVE 1 4101 3 proc/boot/io-usb 10o RECEIVE 4 4101 4 proc/boot/io-usb 10r NANOSLEEP 4101 5 proc/boot/io-usb 10o RECEIVE 4
ここで、 pidはシステム内のプロセス識別子（プロセスID）、 tidはプロセス内のスレッド識別子（スレッドID）、 prioはスレッドの優先順位番号とスケジューリング規則、 STATEはスレッドステータス、 Blockedはブロックの理由に依存する値です。 上記の例では、スレッド2、3、および5は受信ブロック状態です（つまり、他のスレッドからメッセージを受信する準備ができています）。
エピローグ
POSIXの利点と、QNXマイクロカーネルの役割について少し話をしようとしました。 これが面白かったと思います。 実際には、タスク間の相互作用の規律とメカニズムの計画について話すのは良いことですが、この情報がすべて混乱にならないように、別々のトピックでこれを行う方が良いと思いました。 次回はもっと面白いものになると約束します。
その他。 誰かがQNXに興味を持っているなら、私が説明したものすべて、さらにもっと多くのものをQNX Neutrinoのシステムアーキテクチャで読むことができます。 このドキュメントは、Webサイトwww.qnx.com （英語）から電子形式で入手できます。また、ロシア語の翻訳版も印刷されています。
- リアルタイムオペレーティングシステムQNX Neutrino 6.3。 システムアーキテクチャ。 ISBN 5-94157-827-X
- リアルタイムオペレーティングシステムQNX Neutrino 6.3。 ユーザーマニュアル。 ISBN 978-5-9775-0370-9