小島様、

産総研　末廣です。

Takashi Kojima さんは書きました:

> アクティブ状態の時、デアクティブ状態の時の差異について、２点、ご質問があります。
>
> １．ＣＰＵ時間の割り当てなどのリソースは、デアクティブとアテクィブな状態では、どの程度の差異が考えられますか？
>
> 大雑把には、実行スレッドが一つ、少なくなるというように考えているのですが、違っておりますか。
> (ざっと調べてみたところ、Aceのスレッドをミューテックスで止めているのかと思ったので・・・）
> それとも、デアクティブにすることで、もっと多くのリソースを節約することができるのでしょうか。
>
> もし、違っておりましたら、どのファイルを解析すればいいんかなどの指針をいただければ、幸いです。

こちらは実装に大きく依存するので安藤さんに
答えてもらうのが良いでしょう。

> ２．サービスポートは、デアクティブ状態であっても、アクティブの時と同様の働きをすることができるのは仕様ですか？
>
> 以前、サービスポートを使って開発していた際、このようなことが起こったため気になったのでお聞きしました。
> この機能は考えようによっては、便利なのですがポリシーなどの点から適切なのでしょうか。

これは良い問題提起だと思います。
アクティブ(Active状態)、デアクティブ(Inactive状態)は
RTCのメインアクティビティの状態です。
ご存知のように、たとえばモータ制御とかセンサ処理とかを
イメージしています。

これがサービスポートのサービスと独立であるべきかどうか
は使われ方によるのでRTC作成者にお任せするというのが
現在のポリシーです。
ですから基本的には独立で、連動させたい場合はフラッグ変数などで
情報を共有させて処理するというのをRTC作成者がやることになります。

では独立／連動はどういう場面で使い分けることになるのでしょうか。
サービスポートに限らず、入出力ポートも含めて考えると、
独立：activateされる前に情報が欲しい
　サービスポートでの内部情報取得やパラメタの設定など
　入力ポートでの制御入力など
連動：activateされていないと意味がない
　サービスポートでの動作指令など
　出力ポートでのセンサ出力など
という感じでしょうか。
ただパラメタ設定や制御入力に関してはInactiveでも
受け付けて欲しいという意味で独立としましたが、
実際にはActiveになる前に最初のデータが欲しいという
違った意味での連動であることが多いと思います。

入出力ポートは垂れ流しで良いか必ず処理されなくては
ならないかで変わりますし、バッファリングのポリシー
にも関係してきます。

現状では、それぞれのRTC作成者に任されていますが、
誰かがこの辺りを整理してパターン集を作ってくだされば
将来的にはOpenRTMに取り込まれることになるかもしれません。

よろしくお願いします。

小島様

産総研 安藤です

> いつもお世話になっております。
> 中央大学、院生の小島と申します。
>
> アクティブ状態の時、デアクティブ状態の時の差異について、２点、ご質問があります。
>
> １．ＣＰＵ時間の割り当てなどのリソースは、デアクティブとアテクィブな状態では、どの程度の差異が考えられますか？
>
> 大雑把には、実行スレッドが一つ、少なくなるというように考えているのですが、違っておりますか。
> (ざっと調べてみたところ、Aceのスレッドをミューテックスで止めているのかと思ったので・・・）
> それとも、デアクティブにすることで、もっと多くのリソースを節約することができるのでしょうか。

現在の実装では非アクティブ状態のときは、スレッドは空の関数を
実行するという実装になっています。したがって、アクティブ状態と
非アクティブ状態ではスレッドの数に違いはありません。

ただし、実行コンテキストにおいて指定される周期でスレッドを回すために、
sleepかusleepが入っておりますので、非アクティブ状態ではCPU時間を
ほとんど消費しないようにはなっております。

> もし、違っておりましたら、どのファイルを解析すればいいんかなどの指針をいただければ、幸いです。

PeriodicExecutionContext.cpp|h を見てみてください。

> ２．サービスポートは、デアクティブ状態であっても、アクティブの時と同様の働きをすることができるのは仕様ですか？

はいそうです。

> 以前、サービスポートを使って開発していた際、このようなことが起こったため気になったのでお聞きしました。
> この機能は考えようによっては、便利なのですがポリシーなどの点から適切なのでしょうか。

たとえば、仮に非アクティブ状態でサービスポートのサービスが
動かないようにしたとすると、サービスを呼ぶ側（コンシューマ）で、
オペレーションを呼んだときに、どのようにするのが妥当でしょうか？

非アクティブ状態においてサービスポートのサービスオブジェクトを、
（CORBAオブジェクトとして）deactivateすることは簡単にできます。

＃onDeactivatedでManagerからPOAを取得して、CORBAオブジェクト
＃に対して、PortableServer::POA::deactivate_object()
＃を呼び、逆にonActivattedでCORBAオブジェクトに対して、
＃PortableServer::POA::activate_object() を呼べば実現できます。

ただし、非アクティブなCORBAオブジェクトに対してオペレーションを呼ぶと、
呼び出し側（コンシューマ側）では例外が発生します。
＃まぁ、これはこれで構わないとも思いますが。

また、1つのRTCに対して実行コンテキストは複数関連付けることが可能ですので、
EC0ではActiveだけど、EC1ではDeactiveということも起こりえます。
その場合、サービスポートのサービスがどのように動くのが適切でしょうか？
＃これが一番問題ですね。。。

と、いろいろ複雑な問題が絡むので、現状では、
サービスポートのサービスはアクティビティとは独立、
ということにしております。

何か、いいアイディアがあればぜひ教えてください。