[openrtm-users 01359] Re: high CPU load when deactivate python component
Ando Noriaki
n-ando ＠ aist.go.jp
2010年 7月 7日 (水) 01:25:07 JST
安藤です
> 安藤様
>
> 清水です。
>
>> ＃別の実装としては、ECのactivate_component()
>> などの呼び出しから、
>> ＃現在アタッチされているRTCの状態がInactiveかどうかをEC
> 自体が常に補足
>> ＃するという方法もありますかね？
>
> 私が考えていたのは、こちらの方法で、
> 毎周期RTCの状態を調べる必要はありません。
そうなんですが、こちらは同じ状態を2か所で持つのでいやだなと。。。
> RTCの状態遷移図によると、
> 以下のようになっています。
>
> ・INACTIVE -> ACTIVEの状態遷移は、
> activate_component()をトリガーとして発生する。
>
> ・ACTIVE -> INACTIVEの状態遷移は、
> deactivate_component()をトリガーとして発生する。
>
> ・ERROR -> INACTIVEの状態遷移は、
> reset_component()をトリガーとして発生する。
>
> これより、ECをstart/stopするタイミングは、
> 上記のメソッドが呼ばれた時だけになると思います。
> したがって、上記メソッドの内部で
> RTCの状態をチェックしECをstart/stopすれば、
> 最小限の負荷で、RTCの状態とECのstart/stopを
> 連動させることができると考えたわけです。
> また、少々手間ですが、RTCの状態とECのstart/stopを
> 連動させるかどうかをconfで指定できると
> ベストかと思います。
これは全部のRTCがInactiveになったらECが自動でstopped
状態になるということですか？ECのstopped/runningはInactive/Active/Error
状態とは独立なので、RTCの仕様的にもちょっと混乱を招きそうです。
とりあえず、こちらの案も含めて検討してみます。
> ご検討の程、よろしくお願いいたします。
>
> 清水
>
> --- Ando Noriaki <n-ando ＠ aist.go.jp> wrote:
>
>> みなさま
>>
>> 安藤です
>>
>> ほぼ栗原さんからの返答で言い尽くされていると思いますが
> 少し補足を。
>>
>> ECとRTCの関係ですが、PeriodicExecutionContext::svc()
>> がまさに
>> その部分になるかと思います。
>>
>> do
>> {
>> m_worker.mutex_.unlock();
>> while (!m_worker.running_)
>> {
>> m_worker.cond_.wait(); //
>> stopped状態のときここで待つ
>> }
>> if (m_worker.running_)
>> {
>> std::for_each(m_comps.begin(),
>> m_comps.end(),
>> invoke_worker()); // すべてのRTCのアクションを実行
>> }
>> m_worker.mutex_.unlock();
>> if (!m_nowait) { coil::sleep(m_period); }
>> } while (m_svc);
>>
>>
>> invoke_worker()
>> の中身ですが、コンポーネントの現在の状態の
>> アクション (on_何とか)
>> を実行するものだと思ってください。
>> なお、Inactive
>> 状態は、on_何とかに相当する関数がないので
>> ダミーの空の関数が実行されていると思ってください。
>>
>> do-while の for_each
>> の部分を書き下すと、コンポーネントがそれぞれ以下の状態
> にある場合
>>
>> RTC0: inactive
>> RTC1: active
>> RTC2: active
>> RTC3: error
>>
>> do-while の for_each 内
>> RTC0. dummy();
>> RTC1: on_execute();
>> RTC2: on_execute'(;
>> RTC3: on_error();
>>
>> ということになります。したがって、RTC0がinactive状態で
> すが、
>> ループを止めるわけにはいきません。
>>
>> 清水さんがおっしゃるように、すべてのRTCがinactiveの場
> 合は
>> ループを止めてもいいのですが、そうなると、
>> ＃以下適当なコードですが、
>>
>> do
>> {
>> m_worker.mutex_.lock();
>> while (!m_worker.running_)
>> {
>> m_worker.cond_.wait(); //
>> ECのstopped状態のときにここで止まってる
>> }
>> if (m_worker.running_) //
>> ECがrunning状態のとき
>> {
>> m_inactivewait.mutex_.lock();
>> inactivecomps =
>> for_each(m_comps.begin(), m_comps.end(),
>> Inactivecomps()); // (1) Inactiveかどうか調べる
>> while (inactivecomps.num() ==
>> m_comps.size()) {
>> m_inactivewait.cond_.wait(); } // (2)
>> 全部inactiveならwait
>> std::for_each(m_comps.begin(),
>> m_comps.end(),
>> invoke_worker()); // (3) 各RTCのアクションを実行
>> m_inactivewait.mutex_.unlock();
>> }
>> m_worker.mutex_.unlock();
>> if (!m_nowait) { coil::sleep(m_period); }
>> } while (m_svc);
>>
>>
>> という感じで、毎周期すべてのコンポーネントを調べる必要
> があります。
>> ＃別の実装としては、ECのactivate_component()
>> などの呼び出しから、
>> ＃現在アタッチされているRTCの状態がInactiveかどうかをEC
> 自体が常に補足
>> ＃するという方法もありますかね？
>>
>> この部分は、リアルタイム実行される可能性もあるので、こ
> れを
>> 取り込むかどうかは (1) の for_each
>> がどのくらいの時間がかかるかにもよると思います。
>> あと、ロックが追加されている部分と、ECのもうひとつの状
> 態遷移(stopped<->running)
>> との兼ね合いについてもよく考える必要があります。（デッ
> ドロックが起こらないかどうかなど）
>>
>> というわけですので、今後の検討課題とさせてください。
>>
>>
>>
>>
>> 2010年7月6日19:15 kurihara shinji
>> <shinji.kurihara ＠ aist.go.jp>:
>> > 松坂様
>> >
>> > 栗原です。
>> >
>> >
>> 以下は、一つのExecutionContextに対して複数のRTCが登録
> された場合についてです。
>> >
>> >> ・ExecutionContextは直列リストの構造をしている。
>> >
>>
> ExecutionContextは、add_component(rtobj)にて登録されたRTC
> をリストで管理してお
>> >
>> り、whileループの中では、リストに登録されているRTCのア
> クティビティ処理を呼び出し
>> > ます。(正確には、StateMachineから呼ばれます。)
>> >
>> >>
>> ・ただし、あくまで分散コンポーネントモデルなので中央で
> コンテキストを管理している
>> >>
>> サービスがあるわけではなく、各コンポーネント同士がバケ
> ツリレーのような形で
>> >> 実行タイミングを通知しあっている。
>> >
>> RTCのリストに登録してある順番でRTCのon_execute()などを
> 呼びますので、たとえば、
>> >
>> ３つのRTC(A,B,C)が登録されていて、３つのRTCがACTIVE状
> 態であれば、Aのon_execute
>> >
>> ()が戻ってきて、Bのon_execute(),Cのon_execute()のよう
> になります。
>> >
>> よって、各コンポーネント同士が実行タイミングを通知しあ
> っているのではなく、
>> >
>> あるRTCのアクティビティ処理が終了次第、次のRTCのアクテ
> ィビティ処理の実行をECが
>> > 行うといった仕様になっております。
>> >
>> >
>> > 以上、宜しくお願い致します。
>> >
>> >
>> > On Tue, 6 Jul 2010 17:44:54 +0900
>> > Yosuke Matsusaka <yosuke.matsusaka ＠ aist.go.jp>
>> wrote:
>> >
>> >> 栗原さん
>> >>
>> >> 松坂です。
>> >>
>> >> 2010/7/6 kurihara shinji
>> <shinji.kurihara ＠ aist.go.jp>:
>> >> >
>> RTMでは、一つのExecutionContextで複数のRTCを駆動する事
> が可能となっております。
>> >> >
>> 仮に、非アクティブ状態でループを回さないようにした場合
> 、一つのECに複数のRTC
>> >> > が関連付けられてる状況において、一つの RTC
>> が非アクティブ状態の時に、他のアク
>> >> >
>> ティブ状態のRTCまでも駆動関数(on_execute)が実行されな
> いといった事になってしまい
>> >> > ます。
>> >> >
>> >> >
>> 上記のような理由もあり、ExecutionContextのループは、RTC
> の状態に関わらずループ
>> >> > する仕様となっております。
>> >>
>> >> なるほど、理解しました。
>> >>
>> 金広さん、清水さんの議論を読んで、何となく私の理解がず
> れている予感がしていたのですが、
>> >> これでクリアになりました。
>> >>
>> >> ・ExecutionContextは直列リストの構造をしている。
>> >>
>> ・ただし、あくまで分散コンポーネントモデルなので中央で
> コンテキストを管理している
>> >>
>> サービスがあるわけではなく、各コンポーネント同士がバケ
> ツリレーのような形で
>> >> 実行タイミングを通知しあっている。
>> >>
>> >> というわけですね。
>> >>
>> 改良しようとしてもなかなか難しいところですね、、、。
>> >>
>> >> --
>> >> Yosuke Matsusaka, Ph.D
>> <yosuke.matsusaka ＠ aist.go.jp>
>> >> Interaction Modeling Group /
>> >> National Institute of Advanced Industrial
>> Science and Technology (AIST)
>> >> Tel: 029-862-6726 Web:
>> http://staff.aist.go.jp/yosuke.matsusaka/
>> >>
>> >
>> >
>> > --
>> > ----------
>> > 栗原 眞二 <shinji.kurihara ＠ aist.go.jp>
>> >
>> > 独立行政法人産業技術総合研究所
>> > 知能システム研究部門 統合知能研究グループ
>> > 〒305-8568
>> > 茨城県つくば市梅園1-1-1 中央第2
>> >
>> > TEL: 029-861-5956
>> >
>> >
>>
>>
>>
>> --
>> 安藤慶昭＠独立行政法人産業技術総合研究所
>> 知能システム研究部門
>> 統合知能研究グループ 主任研究員, 博士(工学)
>> 〒305-8568 つくば市梅園1-1-1 中央第2
>> e-mail: n-ando ＠ aist.go.jp, web:
>> http://staff.aist.go.jp/n-ando
>> OpenRTM-aist: http://www.openrtm.org
>>
>>
>
>
--
安藤慶昭＠独立行政法人産業技術総合研究所 知能システム研究部門
統合知能研究グループ 主任研究員, 博士(工学)
〒305-8568 つくば市梅園1-1-1 中央第2
e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
OpenRTM-aist: http://www.openrtm.org
Noriaki Ando, Ph.D.
Senior Research Scientist, RT-Synthesis R.G., ISRI, AIST
AIST Tsukuba Central 2, Tsukuba, Ibaraki 305-8568 JAPAN
e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
OpenRTM-aist: http://www.openrtm.org
openrtm-users メーリングリストの案内