[openrtm-users 00354] Re: OutPort のバッファリングについて
Yoshiji Yasu
Yoshiji.Yasu ＠ kek.jp
2008年 2月 7日 (木) 11:12:15 JST
宇田様、
つくばにあります高エネルギー加速器研究機構（KEK)の安と申します。
InPort/OutPortのバッファリングについてコメントさせていただきたいと思います。
私たちのアプリケーションは実はロボットとは直接関係ない、加速器を用いた実
験で検出器からのデータ収集の分野です。組み込み系に分類されるかもしれませ
ん。宇田様が議論されているInPort/OutPortのバッファリングについては、私た
ちのアプリケーションでは大変重要な点です。ロボットの分野では周期的なク
ロックに同期したデータ通信方法を取る場合が多いようですが、私たちのアプリ
ケーションでは（実は組み込み系でも同じだと思うのですが）、データが利用で
きるようになったイベントに同期して通信する方法をとります。ですから、
InPort/OutPortのバッファリングで言えば、 empty/fullでブロックさせるた
め、pthead_cond_timedwaitメソッドを使ってRingBufferを作成します。
timedwaitを使うのはバッファ内で無限ループに陥らないようにするためです。
実は以前のRTミドルウエアは独自のRingBufferを実装できるようにはなっていま
せんでした。すでに２年以上になりますが、加速器を用いた実験で検出器からの
データ収集にＲＴミドルウエアを適用するために、KEKと産総研で共同研究を続
けています。安藤さん、神徳さん、平野さん、たちとの議論を通じで
InPort/OutPortのバッファリングの重要性を理解していただいています。安藤さ
んの努力のおかげで、独自のRingBufferを実装できるようになりました。また、
CORBAばかりでなくTCP socketを用いたデータ通信の手段も実装していただきま
した。細かいところでは、まだ改良の余地があります。宇田様が「InPortでデー
タが引き取られたことをOutPortにフィードバックする機構があると、ハンド
シェークが行えるのでデータの取りこぼしが防げるかもしれません」と言われて
いる点が改良点の１つです。暫定的ですが、それを防ぐ方法を実装しました。
RingBufferばかりでなくＲＴミドルウエアのいろいろなコードの修正が必要でし
た。安藤さんに検討していただいておりますので、ＲＴミドルウエアにいずれ反
映することになると思います。
今後ともよりよいＲＴミドルウエアになるように微力ながら協力してゆきたいと
思っています。
Akio Uda さんは書きました:
> To: 産総研 安藤様
>
> いつも御世話になります。宇田＠NECシステムテクノロジーです
>
> 早速のご回答をどうもありがとうございます。
>
>
>> 宇田様
>>
>> 安藤です
>>
>> いつもお世話になっております。
>>
>>
>>> OpenRTM-aist-0.4.1のOutPortのバッファリングについてご教授下さい。
>>>
>>> OutPortにおいて、ブロックモードでのデータ書き込みを行いたいのですが、
>>> OutPort.hを拝見しますと、write()メソッドの中で
>>>
>>> virtual bool write(const DataType& value)
>>> {
>>> ...
>>> while (m_writeBlock && this->isFull())
>>> {
>>> /* フル状態解消待ち */
>>> }
>>> ...
>>> }
>>>
>>> のようにバッファフルの解消待ちをされているものの、RingBuffer.h では
>>> isFull()が常にfalseを返すように見受けられるのですが、0.4.1 ではまだ
>>> ブロックモードには対応されていないのでしょうか？
>>>
>> RingBuffer.hで定義されているバッファはフル状態にならないバッファですので、
>> ブロッキングをONに設定してもブロッキングされません。
>>
>> OutPort(とInPort)はテンプレートの引数として、バッファを取ることができ、
>> これにより、コンポーネント開発者は独自の機能を持つバッファを
>> OutPortもしくはInPortで使用することができるようになっています。
>>
>> ですので、BufferBaseを継承した独自のバッファがisFullでtrueを返す場合
>> 一応ブロッキングされるはずです。
>>
>
> 了解致しました。では、独自バッファでの実装も検討したいと思います。
>
>
>
>> ただ、この機能はまだ十分にデバッグされておらず、
>> 有効に機能するかどうかはこちらではちょっとわかりません。
>>
>>
>>> またバッファクリアを行いたいのですが、この場合は setReadBlock()で非
>>> ブロックモードを指定した後、read() を false が返るまで繰り返せばよろ
>>> しいでしょうか？（m_readTimeout はデフォルト値 0 を想定しています）
>>>
>> 現在のRingBufferでは、常に最新値を読むので、
>> ご希望のバッファクリアに相当する動作はおそらくしないものと思われます。
>>
>
> この場合、OutPortのread()の使い方としては、例えば最後に書き込んだ
> データの確認などを想定されていますでしょうか？
>
>
>
>> 大変申し訳ないのですが、InPortおよびOutPortの特にバッファ周りは、
>> いま一つ完成度が低く、次のバージョンでは構造的に大幅に見直す可能性があります。
>>
>> 問題の一つとして、0.2.0では一つのOutPortから複数のInPortに
>> つないだ場合、すべてにデータが送信されるのに対して、0.4.0では
>> SubscriptionTypeの組合せによっては、うまくすべてにデータが
>> 送信されないなど、バッファ周りの設計の不備による問題点が明らかになっております。
>>
>> 次期バージョンでは、このあたりの問題をきちんと解決したいと考えております。
>>
>> 何か、ご意見やアイディアなどございましたら、お教えいただけないでしょうか。
>> よろしくお願いいたします。
>>
>
> 了解致しました。
>
> OutPortからInPortへのブロードキャストは多用する可能性がありますので、
> 対応して頂けると助かります。ただ、１つのブロードキャスト内で異なる
> SubscriptionTypeを混在させるシーンは、今のところ思い浮かびません。
>
> また、InPortでデータが引き取られたことをOutPortにフィードバックする
> 機構があると、ハンドシェークが行えるのでデータの取りこぼしが防げる
> かもしれません（ブロードキャストの場合は難しそうですが）。
>
> あと、次期バージョンの大まかなご予定など、もし決まっていましたら
> 教えて頂けますでしょうか？
>
>
> zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
> z 宇田 安規男 z
> z ＮＥＣシステムテクノロジー株式会社 システムテクノロジーラボラトリ z
> z エキスパート z
> z 神奈川県川崎市中原区下沼部 1753 NEC 玉川事業場 N棟30F z
> z 〒 211-8666 Tel: 044-431-7574 Fax: 044-431-7588 z
> z E-mail: uda-axa ＠ necst.nec.co.jp 内線: 8-22-60734 社〒: 22-60600 z
> zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
>
>
>
>
--
Yoshiji Yasu @ Online group, Institute of Particle and Nuclear Studies,
High Energy Accelerator Research Organization ( KEK ),
E-mail : Yoshiji.YASU ＠ kek.jp
openrtm-users メーリングリストの案内