QNX RTOS：インターワーキング

QNXリアルタイムオペレーティングシステムに関する一連の注意事項の続き。 今回は、QNX Neutrinoのタスク間処理についてお話ししたいと思います（QNX 6.5.0を検討します）。 RTOSには、QNX固有のメッセージングから、UNIXおよびPOSIX開発者や共有メモリに馴染みのある信号まで、タスク間相互作用のための幅広いメカニズムがあります。 また、メモのほとんどはメッセージングに当てられますが、信号、POSIXメッセージ、および共有メモリを使用する機能についても説明します。 そして最後まで読んだ人はお茶のために2つのパンを受け取ります。



QNXシステムプログラマには、メッセージングの原理を理解することが必要です。 このメカニズムはRTOSで基本的な役割を果たします。 開発者に馴染みのあるオペレーティングシステムの多くの機能はアドオンに過ぎず、メッセージングを使用して実装されread()



たとえば、 read()



およびwrite()



）。

QNX RTOS InterTaskingフォーム

上記のように、メッセージングは​​QNXのタスク間相互作用の基本的なメカニズムであり、他のメカニズムの基盤となっています。 このノートで説明されているすべての形式のタスク間相互作用を以下の表にリストし、このメカニズムまたはそのメカニズムを実装する責任者を示します。



表1.タスク間相互作用の形式。

メカニズム	実施分野
メッセージング	小核
信号	小核
共有メモリ	procnto プロセスprocnto
POSIXメッセージキュー	mqueue manager
名前なし（パイプ）および名前付き（FIFO）プログラムチャネル	pipe マネージャー

QNX 6.5.0 RTOSでは、別の形式のタスク間対話が登場しました-永続パブリッシュ/サブスクライブ（PPS）。 これはかなり興味深い技術であり、これについては別の機会に書きます。 興味のある方は、「QNX Neutruno System Architecture」 のPPSセクションの翻訳を読むことができます。

メッセージング

これは、QNX Neutrinoマイクロカーネルに実装された同期タスク間メカニズムです。 RTOSを開発する際、この形式のタスク間相互作用が誤ってメインの相互作用として選択されることはありませんでした。 まず、メカニズム自体は非常に単純です。 第二に、メッセージの送信と受信の同期はデバッグを容易にします。 第三に、QNX Neutrinoメッセージングに基づいてモノリシックカーネルに実装された高レベルの相互作用（ソフトウェアチャネルなど）のテストでは、ほぼ同じパフォーマンス特性が明らかになりました。



QNXメッセージングエンジンは、メッセージングで使用される3つの主要機能の最初の文字に基づいて、SRRエンジンとも呼ばれます¹ 。 MsgSend()



はメッセージの送信に使用され、 MsgReceive()



はメッセージの受信に使用され、 MsgReceive()



は呼び出し元への応答の送信に使用されます。 最初に、各機能を個別に見て、どのように機能するかを理解してから、それらを1つの例で組み合わせます。 関数のすべての引数は、注意をそらさず、操作の原則を最初に理解するために、意図的に与えられません。



MsgSend()



は、 クライアントからサーバーにメッセージを送信し、応答を受信するために使用されます。 ここでのクライアントとサーバーの概念はかなりarbitrary意的です。 同じプログラムがいくつかのタスクのサーバーになると同時に、他のタスクのクライアントになることができます。 たとえば、データベースサーバーは、データベースクライアント^2のサーバーです。 同時に、データベースサーバーがファイルシステムマネージャーのクライアントになります。 MsgSend()



関数がMsgSend()



クライアントはSEND



またはREPLY



2つの状態のいずれかでブロックされます。 SEND



ステータスは、 クライアントがメッセージを送信し、 サーバーがまだ受信していないことを意味します。 サーバーがメッセージを受信すると、 クライアントはREPLY



状態に入ります 。 サーバーが応答メッセージを返すと、 クライアントはロック解除されます。



MsgReceive()



は、 クライアントからメッセージを受信するために使用されます 。 サーバーはMsgReceive()



を呼び出し、 クライアントがまだメッセージを送信していない場合、つまりRECEIVE



状態でブロックします 。 MsgSend()



関数を呼び出しませんでした。 この後（メッセージがサーバーに送信されました）。 サーバーはロック解除され、実行を継続します。 サーバーは通常、受信したメッセージを処理し、新しいメッセージを受信する準備をするためにいくつかのアクションを実行する必要があります。 サーバーが複数のスレッドで実行されている場合、別のスレッドがメッセージを処理してクライアントに応答する場合があります 。 ほとんどの場合、メッセージを受信するストリームは「永遠の」サイクルで機能し、受信したメッセージを処理した後、 MsgReceive()



再度呼び出します。



MsgReply()



、応答メッセージをクライアント ³に送信するために使用されます。 MsgReply()



関数がMsgReply()



ロックは発生しません。 サーバーはさらに動作し続けます 。 これは、 クライアントがすでにロック状態（ REPLY



）にあり、追加の同期が必要ないためです。



私たちが持っている知識ブリックからQNXメッセージングメカニズムを理解するための橋渡しをするために、他に何を学ぶ必要がありますか？ そんなにない。 辛抱強く、今、写真が形になり始めます。



QNX Neutrinoマイクロカーネルは、送信されたメッセージの内容を気にしません。 メッセージには形式がありません。 メッセージは、 クライアントとサーバーに対してのみ意味があります 。 マイクロカーネルは、 クライアントアドレス空間からサーバーアドレス空間にメッセージ（つまり、データバッファ）のみをコピーし（応答する場合はその逆）、メッセージを保存するための中間バッファはありません。 そして、それは中間コピーがないことを意味します、なぜなら マイクロカーネルは、 クライアントメモリからサーバーメモリにデータを直接コピーします （応答する場合はその逆）。 その結果、メッセージングエンジンのパフォーマンスが向上します。



メッセージへの送信、受信、および応答を同期するために、マイクロカーネルは、メッセージ交換に参加しているスレッドをSEND



、 RECIEVE



、およびREPLY



3つの状態のいずれかでブロックします。 サーバーがメッセージを受信するまで、 クライアントは SEND



状態でブロックされます。 クライアントがメッセージを送信していない場合、 サーバーは RECEIVE



状態でブロックされます 。 サーバーはメッセージを受信すると、ロックが解除され、 クライアントはREPLY



ブロック状態になります。 サーバーがクライアントに応答を返した後、 クライアントのロックが解除されます。 以上です。



そこで、QNXのメッセージングエンジンがどのように機能するかを見つけました。 図 1は単に上記を示しています。





図 1. QNX Neutrinoでのメッセージング。

クライアントはどのようにしてサーバーを見つけますか？

QNX RTOSのメッセージングエンジンの原理を理解していれば、先に進むことができます。 おそらく、QNXでメッセージを交換することはできません、決定することなく、1つの質問があるはずです。 クライアントはどのようにしてサーバーを見つけますか？



メッセージはスレッド間で直接送信されません。 代わりに、チャネルと接続が使用されます。 サーバーはChannelCreate()



関数を使用してチャネルを作成します。 さて、最後に、 サーバーは明確な良心をもって、 MsgReceive()



およびMsgReply()



呼び出すことができます 。 以下のコードは、 サーバーの動作を示しています 。

 chid = ChannelCreate( flags ); /*    chid  -1 */ for (;;) { rid = MsgReceive( chid, &msg, sizeof( msg ), NULL ); /*    rid  -1 */ switch ( msg.type ) { /*   */ } MsgReply( rid, EOK, NULL, 0 ); /*    ,    */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 クライアントはConnectAttach()



を使用してサーバーチャネルへの接続を作成し、 ConnectAttach()



を呼び出します。 クライアントコードは非常に簡単です。

 coid = ConnectAttach( nd, pid, chid, _NTO_SIDE_CHANNEL, 0 ); /*    coid  -1 */ /*   */ MsgSend( coid, smsg, sizeof( smsg ), rmsg, sizeof( rmsg ) ); /*    ,    */ /*   */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今、最後の質問が残っています。 chid



どのようにchid



サーバーパラメータをchid



： nd



、 pid



、 chid



？ これらのパラメーターは、 サーバーアドレス、または都市コードと内線番号を含む電話番号を表します 。 この質問に対する答えの半分は、 サーバー自体がこれらすべてのパラメーターを知っているということです。 しかし、 サーバーはどのようにしてそれらをクライアントに伝えることができますか？



サーバーからこの情報を取得するには、さまざまな方法があります 。 .pid



ファイルまたはグローバル変数を使用できます。 しかし、小さなアプリケーションの正しい方法は、 サーバーでname_attach()



関数を使用し、 クライアントでname_open()



を使用することです 。 さらに正しい方法は、名前空間要素を担当する場合、 サーバーをリソースマネージャー ⁴として実装することです。

複合メッセージ

すでに述べたように、QNX Neutrinoのメッセージングエンジンの主な利点の1つは、その高いパフォーマンスです。 これは、データの中間コピーがないという事実によって達成されます。 メッセージはクライアントのメモリからサーバーのメモリに直接コピーされます。 これらのメッセージは異なる場所にあることがよくあります。 典型的なケースは、データが機器から受信した生のバッファであり、データ情報（メッセージヘッダー）を持つ構造である場合です。 生データ自体は、リングバッファにある場合があります。 この場合、別のバッファを事前に準備し、そこにあるリングバッファからヘッダとデータをコピーすることが本当に必要ですか？ 余分なコピーになりますか？ 複合メッセージが使用されている場合、QNX RTOSでは、メッセージを送信する前にこのデータを不必要にコピーすることを回避できます。



QNX Neutrinoで複合メッセージをiov_t



するには、メッセージ数と等しい（または大きい）要素数を持つiov_t



型の配列を宣言し、 SETIOV()



マクロを使用して各要素を初期化する必要があります。 各バッファのアドレスとサイズを指定します。 図 図2は、複合メッセージの原理を示しています。





図 2.複合メッセージの例。



複合メッセージを処理するには、よく知られている関数MsgReceive()



およびMsgReply()



、vの終わり、つまり MsgReceivev()



およびMsgReplyv()



メッセージ送信関数MsgSend()



も結果を受け入れるため、 MsgSendv()



、 MsgSendsv()



およびMsgSendvs()



ファミリー全体にMsgSendv()



ています。 これで、マイクロカーネルがすべての追加作業を行い、追加のコピーとメッセージ全体のバッファリングは行われません。 私はそれが好きです！

インパルス

時には、他のスレッドに何かが起こったことを知らせるだけでよく、答えは必要ありません。 したがって、 MsgSend()



ブロックも必要MsgSend()



ません。 この場合、 MsgSendPulse()



関数がMsgSendPulse()



ます。 パルスには、8ビットのコードと32ビットのデータが含まれます。 非常に頻繁に、割り込みハンドラでパルスが使用されます。 パルスの場合、キューが使用されます。 ストリームがしばらくパルスを受信して​​いなくても、パルスは失われません。 ただし、読み取り時間がないストリームにパルスを送信した場合は、遅かれ早かれEAGAIN



エラーを受け取る準備をしてください。

信号

QNX Neutrino RTOSは、UNIX開発者になじみのあるシグナリングメカニズムをサポートしています。 標準のPOSIX信号とPOSIXリアルタイム信号の両方がサポートされています。 両方のタイプの信号を処理するには、同じマイクロカーネルコードが使用されます。 その結果、マイクロカーネル自体がよりコンパクトになり、POSIXリアルタイムシグナルグループの同僚のように、（アプリケーションの要求に応じて）POSIXシグナルをキューに入れることができます。 特に、QNX NeutrinoはPOSIX標準を拡張し、特定のストリームに信号を送信できるようにします。 そして、これは時々非常に便利です。



ところで、POSIXリアルタイム信号には、8ビットのコードと32ビットのデータが含まれています。 何にも似ていませんか？ 正確には、信号メカニズムを実装する同じコードがパルスの送信にも使用されます。 便利で信頼できる。



シグナルを処理するには、おなじみの関数kill()



、 sigaction()



、 sigprocmask()



など、およびより興味深い関数、例えばpthread_kill()



およびpthread_sigmask()



ます。

番組チャンネル

ソフトウェアチャネルは、UNIXユーザーおよび開発者になじみがある必要があります。 QNXには、よく知られているすべてのコマンド、機能、およびトリックもあります。 たとえば、これは名前のないプログラムパイプ（パイプ）がコマンドラインで作成される方法です。

 # ls -l | less
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前付きパイプ（FIFO）を作成するには、 mkfifo



コマンドまたはmkfifo()



関数を使用する必要があります。



機能は1つだけです。 QNX Neutrinoがプログラムチャネルで動作するには、 pipe



マネージャーを実行する必要があります。

POSIXメッセージキュー

メッセージキューは名前付きプログラムパイプ（FIFO）に似ていますが、より複雑なメカニズムです。 メッセージの優先順位付けをサポートします。 QNX NeutrinoでPOSIXメッセージキューを使用するには、 mqueue



マネージャーを実行する必要があります。



QNX RTOSのメッセージキューには複数のスラッシュ文字「/」を含めることができます。これは、ディレクトリを作成できることを意味します。 したがって、POSIX標準は拡張され、キュー名がスラッシュで始まり、この文字を含まないことが要求されます。 として非常に便利な機能 1つのソフトウェアパッケージまたは1つの会社のキューを1つのディレクトリにグループ化できます。

共有メモリ

QNX Neutrinoでの共有メモリの操作は、他のUNIXシステムと同じです。 共有メモリメカニズムは、マイクロカーネルを含むprocnto



プロセスprocnto



実装されているため、他に何も実行する必要はありません。 shm_open()



およびmmap()



関数のドキュメントで詳細を読むことができます。



それとは別に、共有メモリ自体はタスク間相互作用に適していないことに注意する価値があります。 サーバーが共有メモリにのみ書き込みを行い、 クライアントが共有メモリからの読み取りのみを行う場合でも、クライアントが部分的に変更されたデータを読み取る場合があります。 このような間違いは後で見つけるのが難しい場合があるため、まったく行わない方が良いでしょう。 このような状況を排除するには、ミューテックスやセマフォなどの同期プリミティブのいずれかを使用する必要があります。



メッセージングエンジンと共有メモリを使用しながら、タスク間の相互作用を行う方法もまた興味深いものです。 これは、分散システムの構築を計画している場合に特に便利です。 共有メモリはネットワーク経由では利用できません。 このソリューションは、共有メモリを使用しているため非常に高いパフォーマンスを発揮し、メッセージングを介した同期機能とネットワーク透過性も備えています。



これが最速の方法であるという事実に基づいて、共有メモリを使用して対話を構築しようとしないでください。 同期プリミティブを使用する場合、速度はメッセージングエンジンの速度に匹敵する可能性があります。 重要な利点は、非常に大容量のデータの交換のみです。

約束のパン

私はパンがあると約束したので、そうです。 私は全く忘れませんでした、そして、私は気にしません。 最初のバンは、メッセージを送信するときに、メッセージ自体に同じバッファを使用して返信できることです。 私は彼らがそれをかなり頻繁に行うとさえ言うでしょう。 より便利にするために、さまざまなメッセージとそれらへの応答を記述するすべての構造が1つの結合にグループ化されます。 通常、 サーバーから応答を受信した後、メッセージはクライアントに送信されません。 したがって、バッファを節約できます。



2つ目は、QNX NeutrinoのPOSIXファイル記述子が接続（メッセージ送信用）と同じであることです。 そして、これは、ファイル記述子（ write()



、 read()



など）を使用する関数が、引数をサーバーへのメッセージに変換するわずかなオーバーヘッドを持つ単なるラッパーであることを意味します 。 十分な深刻な最適化。 したがって、QNX用のシステムソフトウェアを開発する場合は、リソースマネージャーの作成方法を学んでください。

参照資料

1. リアルタイムオペレーティングシステムQNX Neutrino 6.3。 システムアーキテクチャ。 ISBN 5-94157-827-X
2. リアルタイムオペレーティングシステムQNX Neutrino 6.3。 ユーザーマニュアル。 ISBN 978-5-9775-0370-9
3. Rob Krten、「QNX Neutrinoの紹介2.リアルタイムアプリケーション開発者向けガイド」、第2版。 ISBN 978-5-9775-0681-6

---

¹関数MsgSend()



などの名前のプレフィックスMsg



はQNX Neutrinoにのみ登場し、QNX4ではこれらの関数は単にSend()



、 Receive()



、およびReply()



と呼ばれていました。 したがって、名前はSRRです。



²この例では、データベースサーバーとクライアントはメッセージング機能を直接使用していませんが、QNXでは、各read()



、 write()



、 sendto()



などの下で、SRRメカニズムが非表示になっていることがすでにわかっています。



³サーバーがエラーコードのみを返す必要がある場合、たとえばメッセージがサポートされていない場合、 MsgError()



関数を使用する方が便利です。



⁴リソースマネージャーの説明は、この記事の範囲外です。 いつかそれについて書くことは可能です。