SObjectizerのユーザーのプロンプトや要望の結果としてSObjectizerに新しい機能が追加されたとき、私たちは非常に満足しています。 これは常に簡単ではありませんが 。 実際、一方では、SObjectizerの開発者と古いユーザーのチームとして、SObjectizerの使用方法に関する独自のステレオタイプをすでに持っています。 また、「外部からの新鮮なビュー」をすぐに評価して、ユーザーがフレームワークで本当に見たいものと、利用可能な手段に満足していない理由を理解することは常に可能とは限りません。 一方、SObjectzerはそれほど小さなフレームワークではないため、新しい機能を追加するには注意が必要です。 新しい機能が既存の機能と競合しないことが必要です。 そしてさらに、既に存在し、長い間働いてきた新しい何かを追加した後、壊れないように。 さらに、SObjectizerのバージョン間の互換性を維持する点がありますので、根本的な変更に強く反対しています...



一般に、SObjectizerに新しいものを追加することは、フレームワークの機能を向上させ、使いやすさを向上させるという点で常に快適です。 しかし、それは常に、実装の観点から見ても同じくらい快適でシンプルです。



カットの下には、SObjectizerに1つの新しい機能が追加された方法についての短いストーリーがあります。 読者の中には、古いフレームワークが新しいユーザーの要求にどのように適応するかを知りたいと思う人もいるかもしれません。

前文

そのため、SObjectizerのユーザーの1人であるPavelVainermanが、SObjectizerにはエージェント間の一時的な対話を実行するための既製の便利なツールがないという事実に注目しました。



これが意味するものであることが判明しました。 エージェントAがエージェントBにリクエストを送信し、エージェントBから応答メッセージを受信したいとします。しかし同時に、エージェントAは5秒以上の応答を待ちたくないと仮定します。 すぐに思い浮かぶ些細な「額」のソリューションは、次のようになります。

//  -. struct request { const so_5::mbox_t reply_to_; //   . ... //  ,   .. }; //  -. struct reply { ... }; class A : public so_5::agent_t { // ,       -. struct reply_timed_out final : public so_5::signal_t {}; ... //  . void on_reply(mhood_t<reply> cmd) {...} void on_reply_timeout(mhood_t<reply_timed_out>) {...} ... // ,       B. void ask_something(const so_5::mbox_t & B_mbox) { //         -. so_subscribe_self().event(&A::on_reply); so_subscribe_self().event(&A::on_reply_timeout); //   .     mbox,   //   . so_5::send<request>(B_mbox, so_direct_mbox(), ...); //       ,   -. so_5::send_delayed<reply_timed_out>(*this, 5s); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、この単純なバージョンは、「複雑なタスクには単純で理解しやすい間違った解決策がある」という格言の真実性を明確に示しているだけです。 ここにはいくつかの問題があります。



最初の問題は、保留中のメッセージA :: reply_timed_outに関連しています。 エージェントBからの応答が時間通りに到着しなかった場合は、reply_timed_outを使用してすべてが順調です。 取得して処理し、それを忘れます。 しかし、エージェントBからの応答が時間通りに到着した場合はどうなりますか？ reply_timed_outはどうなりますか？



エージェントAに届きます。reply_timed_outをキャンセルした人はいません。 したがって、SObjectizerタイマーのスレッドが設定された5秒をカウントダウンするとすぐに、reply_timed_outメッセージがエージェントAに配信されます。必要がなくなったにもかかわらず、それを受信して​​処理します。 何が悪いの。 エージェントBから返信を受け取った後、reply_timed_outメッセージが届かないようにすることは正しいでしょう。



これを行う最も確実な方法は、reply_timed_outからサブスクライブを解除することです。 まさにこれが別の大きな会話のトピックである理由。 誰かが興味を持っている場合は、このトピックについて個別に話すことができます。 それまでの間、遅延メッセージの登録解除は、遅延メッセージの問題を解決するための「強化された具体的な」オプションであるという事実に限定されています。



2番目の問題は、エージェントAがこの方法でエージェントBとのみ通信する必要がないことです。おそらく、エージェントAは、一度に複数のエージェントと要求/応答メッセージを交換します。 したがって、リクエストがエージェントBとCに同時に送信された場合、エージェントAは応答の送信元を何らかの方法で理解する必要があります。 または、5秒以内に応答が受信されなかった。



2番目の問題は、自分のmboxエージェントAを返信先アドレスとして使用することを拒否することにより、多少なりとも便利に解決されます。 新しいインタラクションごとに新しいmboxを作成する方が簡単です。 そして、この新しいmboxが、応答を受信し、この特定の要求の保留中のメッセージに使用されます。



ただし、新しいmboxを導入したらすぐに、mboxが不要になったら削除する必要があります。 これを行うには、このmboxのサブスクリプションを削除する必要があります。 サブスクリプションが削除されない場合、mboxは存続します。これにより、メモリ消費が常に増加します。新しいリクエストごとに新しいmbox-sを作成し、これらのmbox-sは削除されません。



一般に、これらの2つの問題を考慮すると、単純な解決策は非常に単純ではないものに変換されます。

 class A : public so_5::agent_t { // ,       -. struct reply_timed_out final : public so_5::signal_t {}; ... //       , //     ,    . void on_reply(const request_info & info, mhood_t<reply> cmd) {...} void on_reply_timeout(const request_info & info, mhood_t<reply_timed_out>) {...} ... // ,       . //       ,  . void ask_something(const request_info & info, const so_5::mbox_t & dest) { //    mbox      . const auto uniq_mbox = so_environment().create_mbox(); //       . auto subscriptions_dropper = [this, uniq_mbox] { so_drop_subscription<reply>(uniq_mbox); so_drop_subscription<reply_timed_out>(uniq_mbox); }; //         -. so_subscribe(uniq_mbox) .event([this, info, subscriptions_dropper](mhood_t<reply> cmd) { //  . subscription_dropper(); //   . on_reply(info, cmd); }) .event([this, info, subscriptions_dropper](mhood_t<reply_timed_out> cmd) { subscription_dropper(); on_reply_timeout(info, cmd); }); //   .      mbox,  //      . so_5::send<request>(B_mbox, uniq_mbox, ...); //       ,   -. so_5::send_delayed<reply_timed_out>(so_environment(), uniq_mbox, 5s); } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちが望むほど単純でコンパクトではないことが判明しました。 しかし、これはすべてとは程遠いものです。 したがって、このソリューションには例外的な安全性はありません。 不要になった保留中のメッセージは、明示的にキャンセルされません。 しかし、もっと重要なことは、エージェントAが上記の例のように1つのデフォルト状態ではなく、それぞれ異なるメッセージに応答する必要がある複数の状態を持ちたい場合、すべてがさらに悪化します。 AとBの間の交換に1つの応答メッセージではなく、複数の応答メッセージが必要な場合、すべてがさらに悪化します。 たとえば、返信の代わりにsuccessed_replyとfailed_replyがある場合、エージェントAの開発者の作業量は著しく増加します。

なぜ私たちはそんな問題に直面しなかったのですか？

側に小さな後退。 PavelVainermanが私たちに言っていることが明らかになったとき、私たち自身が驚きました。 結局のところ、問題は本当に明らかです。 しかし、なぜ私たちは自分自身でそれを見つけなかったのですか？ 少なくとも注意を喚起し、この問題の解決策をSObjectizerに含めるために、あまり頻繁には遭遇しません。



ここにはおそらく2つの要因がありました。



まず、 SEDAアプローチのアイデアをすぐに思い付きました 。 そこでは、エージェントの数が少なく、エージェント間で安定した通信が確立されるため、そのような問題は原則としてありません。



第二に、おそらく、私たちとの1回の1回限りの対話は、短命エージェント間で最も頻繁に使用されます。 そして、単一の操作を処理するためだけに生きるエージェントにとって、これらの問題は関係ありません。



新しい人があなたのツールを使い始めるとすぐに、彼らがあなたがあなたがそれをするのに慣れている方法とはまったく異なる方法でツールを使いたいとすぐに判明するという事実に注意することは不可能かもしれません。

最後に何をしましたか？

その結果、SObjectizerのアドオンをso_5_extraという名前で拡張し、いわゆるサポートを追加しました。 非同期操作 。 非同期操作により、上記の例を次のように書き換えることができます。

 class A : public so_5::agent_t { // ,       -. struct reply_timed_out final : public so_5::signal_t {}; ... //     , //     ,    . void on_reply(const request_info & info, mhood_t<reply> cmd) {...} void on_reply_timeout(const request_info & info, mhood_t<reply_timed_out>) {...} ... // ,       . //       ,  . void ask_something(const request_info & info, const so_5::mbox_t & dest) { //    mbox      . const auto uniq_mbox = so_environment().create_mbox(); //     . so_5::extra::async_op::time_limited::make<reply_timed_out>(*this) .completed_on(uniq_mbox, so_default_state(), [this, info](mhood_t<reply> cmd) { on_reply(info, cmd); }) .timeout_handler(so_default_state(), [this, info](mhood_t<reply_timed_out> cmd) { on_reply_timeout(info, cmd); }) .activate(5s); //   .      mbox,  //      . so_5::send<request>(B_mbox, uniq_mbox, ...); } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

so_5_extraの新しい非同期操作の詳細については、 こちらをご覧ください 。



しかし、今日は非同期メッセージ自体の作成方法については説明しません。 また、so_5_extraで非同期メッセージを機能させるためにSObjectizerで行う必要のあったことについて。

time_limited非同期操作の実装の問題は何でしたか？

So_5_extraには、非同期操作の2つの実装が含まれます。time_unlimited（操作の実行時間にまったく制限がない場合）とtime_limited（操作を割り当てられた時間内に完了する必要がある場合）。 上記では、ほぼtime_limited操作でした。 主な障害の1つであったのは実装でした。



一番下の行は、time_limited操作を開始するときに、保留中のメッセージを確実に受信して処理する必要があるため、非同期操作の時間を制限しています。 そして、これは「必然的に」すべてが単純ではありませんでした。



実際には、SObjectizerの重要な機能の1つはエージェントの状態です 。 状態により、エージェントは状態ごとに異なるメッセージセットを処理できます。 または、異なる状態で同じメッセージを異なる方法で処理する。 ただし、すべての状態でメッセージを処理する必要がある場合は、状態ごとにメッセージハンドラーに明示的に署名する必要があります。 つまり 次のように書きます：

 class default_msg_handler_demo : public so_5::agent_t { //   . state_t st_first{this}, st_second{this}, st_third{this}; ... // ,       . void some_msg_default_handler(mhood_t<some_msg> cmd) {...} ... virtual void so_define_agent() override { ... //    " ". so_subscribe(some_mbox) .in(st_first).in(st_second).in(st_third) .event(&default_msg_handler_demo::some_msg_default_handler); ... } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

当然、これは最良かつ最も便利なソリューションではありません。



階層状態マシンの機能を使用することで、より簡単で便利になり、信頼性を高めることができます。

 class default_msg_handler_demo : public so_5::agent_t { //   . //   . state_t st_parent{this}, //    ,   . st_first{initial_substate_of{st_parent}}, st_second{substate_of{st_parent}}, st_third{substate_of{st_parent}}; ... // ,       . void some_msg_default_handler(mhood_t<some_msg> cmd) {...} ... virtual void so_define_agent() override { ... //    " "    . so_subscribe(some_mbox) .in(st_parent) .event(&default_msg_handler_demo::some_msg_default_handler); ... } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、エージェントの状態に関係なく、「デフォルト」ハンドラーが呼び出されます。



しかし、残念ながら、このアプローチでは、エージェントが階層状態マシンを使用して最初に設計される必要があります。 so_5_extraからの非同期操作を使用することは、ユーザーにそのような厳しい要件を課した場合には便利ではないでしょう。エージェントで親状態を作成してください。



そして、これを行うことは原則として常に可能ではありません。 基本型basic_device_managerを持つエージェントライブラリを誰かが書いたとします。 独自の継承クラスmy_device_managerを作成し、my_device_managerで非同期操作を使用する必要があります。 開発者がbasic_device_managerでst_parentなどを行わなかった場合、そこにst_parentを追加しません。



一般的に、エージェント宛てのメッセージをキャッチするものの、エージェントによって処理されなかったメッセージをキャッチする必要がありました。 そのようなメッセージは、時々 デッドレターと呼ばれます 。

私たちは何をどうやってやったのですか？

デッドレターハンドラー

開発者が「通常の」ハンドラーによって処理されなかったメッセージに自分のハンドラーを掛けることができるようにしました。 例：

 class deadletter_handler_handler_demo : public so_5::agent_t { state_t st_first{this}, st_second{this}, st_third{this}; ... void deadletter_handler(mhood_t<some_msg> cmd) {...} ... void normal_handler(mhood_t<some_msg> cmd) {...} ... virtual void so_define_agent() override { ... //  ""    st_first. so_subscribe(some_mbox) .in(st_first).event(&deadletter_handler_demo::normal_handler); //   "" . so_subscribe_deadletter_handler(some_mbox, &deadletter_handler_demo::deadletter_handler); ... } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、エージェントがst_first状態のときにsome_mboxメールボックスからsome_msgメッセージを受信すると、メッセージを処理するためにnormal_handlerが呼び出されます。 ただし、エージェントが他の状態にある場合、このメッセージを処理するためにdeadletter_handlerが呼び出されます。



この機能はtime_limited操作で使用されます。 操作がアクティブになると、deadletter_handlerはタイムアウトの期限切れに関するメッセージでハングアップします。 また、このメッセージが到着した時点でエージェントの状態が何であっても、メッセージは受信されて処理されます。 これにより、非同期操作を完了できます。 開発者が間違っていて、必要なすべてのタイムアウトハンドラを定義しなかった場合でも。

実装されていない魅力的なアイデア

デッドレターハンドラーの問題が定式化されるとすぐに生じた最初の考えは、各エージェントに何らかの親の状態を提供することでした。 そして、他のすべての州は自動的にその子会社になります。 つまり 各エージェントにスーパーステートを強制するという考えがありました。 それはそこにあり、それについては何もできません:)



このアイデアは、サブスクリプションを保存および検索する現在のメカニズムの観点から非常に魅力的でした（このメカニズムはそれほど単純ではありません）。



また、この考えはイデオロギーの観点から非常に美しいです。 階層的な有限状態マシンがそのまま。



しかし、私はそれを放棄しなければなりませんでした（おそらくしばらくの間？）。



失敗の主な理由は、state_tオブジェクトがかなり重いことです。 コンパイラ、標準ライブラリ、およびコンパイルオプションに応じて、64ビットモードのstate_tは150〜250バイトかかる場合があります。 各エージェントにスーパーステートを強制的に追加すると、各エージェントの「重み」が1.5バイトから200バイト増加します。 ちょうどそのように、突然です。 このエージェントがスーパーステートをまったく必要としない場合でも。



さらに別の理由があり、実際にあります。 各エージェントのスーパーステートは、SObjectizerにとって大きな革新であり、過酷な湾からそれを作るには大きすぎます。

すべての結果を慎重に検討することなく。 私は個人的に大きな疑いを持っています

SObjectizerにスーパーステートを追加する価値があり、それが悪用され始めます。



一般に、スーパーステートのアイデアはバージョン5.5.21では機能しませんでした。 しかし、ノッチは記憶に残りました。 おそらく彼女はまだ彼女の体現を見つけるでしょう。 誰もがこれについて考えているなら、聞いて議論するのは面白いでしょう。

実際の解決策

彼らはスーパーステートの概念を放棄しましたが、それでもサブスクリプションを保存するための現在のメカニズムを変更したくありませんでした。 したがって、追加のstate_tオブジェクトが必要であるという解決策が見つかりました。 しかし、 彼はすべてのために存在し 、すべてのエージェントは彼を参照します。



これにより、デッドレターハンドラーの登録と検索に同じツールを使用することができました。 実際、so_subscribe_deadletter_handlerは、ユーザー状態には見えない特別なメッセージハンドラサブスクリプションにすぎません。 さて、メッセージのデッドレターハンドラーの検索は、ハンドラーの通常の検索にすぎませんが、エージェントの現在の状態ではなく、この特別な不可視状態を検索します。 確かに、メッセージ配信メカニズムのトレースモードがオンになっている場合、 いくつかの追加のアクションがありますが、これらはすでに退屈な詳細です。

すべてがとても明白でシンプルでしたか？

出版前にこの記事を読んだとき、ある種の些細なことが言われていると思った。 まあ、すべてがシンプルで明確なようです。 しかし、この「シンプルで明確な」道は、迅速でもなく、直接的でも、明白でもないことが判明しました。 誰もが興味を持っている場合、非同期操作のアイデアの進化の痕跡は、ブログ記事のこのミニシリーズで見つけることができます： No.1 、 No.2 、 No.3 。 結局のところ、このシリーズの最後の投稿でさえ、結果のソリューションを説明していませんでした。 私は自分自身の重大な誤算につまずかなければならず、オブジェクト間の循環リンクが存在する場合にメモリリークを防ぐ方法について困惑していました。 しかし、これは全く異なる話です...

結論にいくつかの言葉

最初にありがとう...

SObjectizerの開発を手伝ってくれたすべての人に感謝します：SO-5を使用して自分の考えや提案を表現してくれた人（ここPavelVainermanに特別な感謝を捧げます ）、まだSO-5を使っていないが、ヒントなどを手伝ってくれている人（ありがとう、特に、 masterspline ）、およびgithubのさまざまなリソースとスターのSObjectizerに関するニュースに+1を入れるのが面倒ではない人だけ:)どうもありがとう！

...そして、近い将来の計画について簡単に

近い将来、5.5.22という番号でSObjectizerの次のバージョンの作業を開始する予定です。 5.5.22で見たい主な新機能は、エージェントの並列状態のサポートです。 エージェントはすでに階層状態の高度な機能を使用できます。 状態のネスト、状態の浅い履歴と深い履歴、入力/出力ハンドラー、状態を維持するための時間制限など。 ただし、SObjectizerにはまだ並列状態がありません。



一時は、何らかの理由でそれらをしませんでした。 しかし、実際には、一部のユーザーは並行状態を必要とし、生活を楽にすることが示されています。 だから私たちはそれらを行います。 誰もが議論に招待されています。建設的な考慮事項、特に練習や個人的な経験からの例は、私たちにとって非常に役立ちます。



まあ、一般に、SObjectizerの印象、好きなもの、嫌いなもの、SO-5に持ちたいものを見つけることは興味深いことです...それはもちろん、SObjectizerに関する質問に答える準備ができています。