この記事からの続きです。

RTAIで何が出来るか？の「IPC」編その１です。

• メッセージ

についてまとめます。

なお、RTAI入門（２）のタスクのリアルタイム化は、全ての基礎となっています。ですから、ここだけはご一読をお勧めします。

メッセージ

概要

リアルタイムタスクが複数あるとき、これらをうまく協調動作させないといけません。

そのための仕組みの１つに、「メッセージ」という機構があります。

メッセージとは、タスクからタスクへとデータを運んでくれる仕組みです。

図１　「メッセージ」は、タスクからタスクへデータを運ぶ

運べるデータに特に制限はありません。ですが、だいたい数バイト～数百バイト程度の使用を想定しています。

メッセージとタスク挙動

じつは、メッセージとは単にデータを受け渡しするだけのものではありません。ただデータを受け渡したいだけなら、グローバル変数でも使えば十分です。

メッセージのキモは、データの受け渡しよりもむしろ、それにともなうタスクの挙動の方にあります。

メッセージとタスク挙動は次のようにまとめられます。

• メッセージは、特定のタスクに向けて送信できる
• メッセージを送信するときに・・・
  • 受信タスクがメッセージ受け取り準備できていなければ、送信タスクはブロックする
  • 受信タスクがメッセージ受け取り準備できていれば、送信タスクはブロックしない
• メッセージを受信するときに・・
  • メッセージがどこからも来ていなければ、受信タスクはブロックする
  • メッセージがどこかから来ていれば、受信タスクはブロックしない

ここで「ブロック」とは、タスクが一時停止する事をいいます。たとえば某ダム建設が、予算うんぬんでモメて工事止まってますよね。あれも、「工事タスク」がブロックしている状態と言えます。（ダムの場合は、ブロックどころかそのままタスクがKillされそうな勢いですが・・・）

ではここで、もう少し具体的に見てみましょう。

まず、ここにタスクが２つあるとします。タスク１から、タスク２に対してメッセージを送りたいものとしましょう。

これらのタスクは、次のように振る舞います。

• タスク２は、普段は何か別の処理をしている。する処理がなくなってヒマになったら、何かメッセージが来ないか待ちかまえる

「何かメッセージが来ないか待ちかまえる」というのが、「メッセージ受け取り準備」に相当します。ＲＴＡＩでは、rt_receive というＡＰＩを使用します。

• タスク１は、気が向いたらタスク２にメッセージを渡したがる

「メッセージを渡したがる」というのが、「メッセージ送信」に相当します。ＲＴＡＩでは、rt_send というＡＰＩを使用します。

この時のパターンとして３つ考えられます。

パターン１

タスク２が準備できてないのに、タスク１がメッセージを渡そうとした

図２ タスク２が準備できてないのに、メッセージを渡そうとした

ここで、（１）と（２）ではそれぞれ次のような会話がなされています。

（１）タスク１がメッセージを渡そうとした

タスク１　「これ、あたらしいメッセージです！読んで下さい！」（＝ rt_send ）
タスク２　「まだ他の仕事してるんだってば！受け取らないよ！？」
タスク１　「スミマセン。準備できるまでずっと待ってます・・・」（＝ブロック）

（２）タスク２がやっと準備完了した

タスク２　「えーっと、次のメッセージは・・・」（＝ rt_receive )
タスク１　「はい！待ってました！ずっと！　さぁ、これです！！！」 ( = ブロック解除 ）

こんな感じで、メッセージ送信側であるタスク１は、rt_send を実行したとたんブロックします。

そのブロックが解除されるのは、メッセージ受信側であるタスク２が rt_receive を実行したときです。

パターン２

タスク２が準備できてから、メッセージを渡した。かつ、タスク２の方が優先度が高い

パターン２、パターン３では、設定を付け加えます。このシステムは１CPUとします。ですから、タスク１、タスク２のいずれかしか実行できません。

その場合、実行されるのは優先度の高いほうのタスクです。

まずパターン２では、優先度を　タスク１　＜　タスク２　とします。

図３　タスク２の準備が先にできた。そのあとからメッセージをわたした。

（１）タスク２の準備が先に完了した

タスク２「えーっと、次のメッセージは・・・」( = rt_receive )
タスク２「えっ、無いの！？じゃあ、寝て待つか・・・」（＝ブロック）
タスク１「よぅし！じゃまなタスク２が居なくなったぞ。さっそく活動開始だっ！」

（２）タスク１がメッセージの準備完了した

タスク１「メッセージ準備できました！」（＝rt_send 、ブロックしない）
タスク２「よしきた！これで仕事を続けられるぞ！」（＝ブロック解除）
タスク１「ちっ。タスク２が活動を始めたか。これじゃあ動けないな・・・」（＝ブロックされてはいないが、動けない）

ここで（２）の段階では、タスク１、タスク２ともにブロック解除されています。

だからどのタスクが動いても不思議ではありません。 しかし、ＲＴＡＩでは常に優先度の高いタスクがＣＰＵを占有するようになっています。

ですからこの場合は、優先度の高いタスク２が動く事になります。

パターン３

タスク２が準備できてから、原稿を渡した。かつ、タスク１のが優先度が高い

パターン２と似ていますが、優先度を　タスク１　＞　タスク２　とします。

図４　タスク２の準備が先にできた。そのあとからメッセージをわたした。

（１）タスク２の準備が先に完了した

タスク２「えーっと、次のメッセージは・・・」( = rt_receive )
タスク２「えっ、無いの！？じゃあ、寝て待つか・・・」（＝ブロック）

（２）タスク１がメッセージの準備完了した

タスク１「メッセージ準備できました！」（＝rt_send 、ブロックしない）
タスク２「よしきた！これで仕事を続けられるぞ！」（＝ブロック解除）
タスク２「え？タスク１のが優先！？そっか・・・うん、わかった」（＝ブロック解除されてはいるが、動けない）

ここで（２）の段階では、タスク１、タスク２、ともにブロック解除されています。

パターン２と違い、最優先なのはタスク１です。そのため、優先度の高いタスク１が動く事になります。タスク２が動けるのは、タスク１が何らかの理由でブロックされたりした時だけです。

まとめ

このように、

rt_send が先か？ rt_receive が先か？
送信タスク、受信タスクのどちらが優先度が高いか？

この２つの問題の兼ね合いによって、タスクの挙動が変わります。

さて、これらの挙動はあくまで典型的なものです。以降では、もっといろんな種類のメッセージ送受信についてご紹介します。

条件付きメッセージ送信

上記の例では、メッセージ送信しようとしたときに、次のように振る舞いました。

• 対象タスクが、すでに rt_receive していたら、送信元はブロックしない
• 対象タスクが、まだ rt_receive していなければ、送信元はブロックする

ＲＴＡＩでは、さらに次のようなメッセージ送信方法が用意されています。

ブロックしないメッセージ送信

送信元がブロックしてもらっては困る場合もあります。その場合には、rt_send_if というＡＰＩを使います。すると次のように振る舞います。

• 対象タスクが、すでに rt_receive していたら、メッセージを渡す。送信元はブロックしない
• 対象タスクが、まだ rt_receive していなければ、メッセージは渡さずにあきらめる。送信元はブロックしない

このように、対象タスクがrt_receive しなければ、さっさとあきらめてしまいます。根性のないやつめ！

決められた時間だけブロックするメッセージ送信

送信元がちょっとブロックする分にはいいけど、ずーっとは困る。そういう場合には、 rt_send_timed というＡＰＩを使います。

• 対象タスクが、すでに rt_receive していたら、メッセージを渡す。送信元はブロックしない
• 対象タスクが、まだ rt_receive していなければ、決められた時間だけブロックする。
  それでもまだ対象タスクがrt_recieveしてくれなければ、メッセージは渡さずにあきらめる。そしてブロック解除する。

このように、対象タスクがrt_receiveしてくれるまである程度の時間だけ待機します。それでもダメならあきらめます。

条件付きメッセージ受信

メッセージ送信と同様、メッセージ受信でも条件付き挙動が可能です。

典型的な挙動は、次の通りです。

• どこかのタスクが、すでに rt_send してくれていたら、受信タスクはブロックしない
• どのタスクも、まだ rt_send してくれていなければ、受信タスクはブロックする

ＲＴＡＩでは、さらに次のようなメッセージ受信方法が用意されています。

ブロックしないメッセージ受信

rt_receive_if というＡＰＩを使うと、次のように振る舞います。

• どこかのタスクが、すでに rt_send してくれていたら、メッセージを受け取り、受信タスクはブロックしない
• どのタスクも、まだ rt_send してくれていなければ、メッセージ受信はあきらめる。受信タスクはブロックしない

このように、メッセージが来ていれば受け取ります。しかし、そうでなければ、さっさとあきらめてしまいます。

決められた時間だけブロックするメッセージ受信

rt_receive_timed というＡＰＩを使うと、こうなります。

• どこかのタスクが、すでに rt_send してくれていたら、メッセージを受け取る。受信タスクはブロックしない
• どこかタスクが、まだ rt_send してくれていなければ、受信タスクは決められた時間だけブロックする。
  それでもま誰も rt_recieveしてくれなければ、メッセージ受信はあきらめる。そしてブロック解除する。

このように、どこかのタスクがrt_sendしてくれるまである程度の時間だけ待機します。それでもダメならあきらめます。

次回

次回は、IPC編その２として、メールボックスについて書きます。