この記事は、2月C ++ CoreHard Winter 2017カンファレンスの同名のレポートのテキストバージョンの最初の部分です。 たまたま15年間、 SObjectizerフレームワークの開発を担当してきました。 これは、アクターモデルを使用できるオープンソースC ++フレームワークをまだ開発している数少ないものの1つです。 したがって、この間、私は実際に俳優のモデルを繰り返し試してみました。その結果、いくつかの経験が蓄積されました。 基本的には前向きな経験でしたが、事前に知っておくと良いと思われるいくつかの明白な瞬間があります。 踏まれたレーキ、コーンがいっぱいになったもの、生活を簡素化する方法、およびそれがSObjectizerの開発にどのように影響したかについては、後で説明します。

私が話すことの多くは、Erlangコミュニティでよく知られていると思います。 しかし、ErlangコミュニティはC ++コミュニティとわずかに重複しています。 さらに、Erlang開発者が利用できるものとC ++開発者が利用できるものには違いがあります。 したがって、この記事がC ++のニックネームにとって興味深く有用であることを願っています。

SObjectizer自体は、2002年春にIntervaleで登場しました。 SObjectizerは、作業ツールとしてのみ作成されました。 そのため、彼はすぐに「ビジネスに参入」し、社内および社外のいくつかの製品で使用されました。

• 電子商取引およびモバイル商取引。
• モバイルバンキング;
• SMS / USSDトラフィックの集約。
• シミュレーションモデリング;
• 鉄道輸送のACSをチェックするためのテストベンチ。
• 測定情報を収集するための分散システムのプロトタイピング。

これらの製品の一部はまだ稼働中です。

モデルアクターの関連性についてのいくつかの言葉

モデルアクターの要点を簡単に更新します。

• アクターは振る舞いを持つエンティティです。
• アクターは着信メッセージに応答します。
• メッセージを受信すると、アクターは次のことができます。
  
  
  • いくつかの（最終的な）メッセージを他のアクターに送信します。
  • （最終的な）数の新しいアクターを作成します。
  • 後続のメッセージを処理するための新しい動作を定義します。

アクターモデルは、アプリケーションでのアプリケーション作業が、非同期メッセージを介してのみ相互作用する別個のエンティティ、アクターによって実行されることを意味します。

アクターは、着信メッセージを待ってスリープし、着信メッセージが表示されると、ウェイクアップしてメッセージを処理し、次のメッセージを受信するまで再びスリープ状態になります。

歴史的な理由から、SObjectizerではアクターではなくエージェントという用語を使用しているため、両方の用語はテキストの後半で使用され、同じ意味を持ちます。

そして、C ++でのアクターモデルの適用可能性に関するいくつかの言葉

私個人の意見では、C ++でアクターモデルを使用すると、多くのボーナスが得られます。

• 各俳優には独自の状態があり、それは自分だけが使用できます。 これにより、マルチスレッドプログラミングの寿命が大幅に簡素化されます。
• 非同期メッセージを介した情報転送は、いくつかのタイプのタスクを解決する便利で自然な方法です。 そして、そのようなタスクのアクターのモデルは、サブジェクトエリアと実装の間のセマンティックギャップを減らします。
• アクターのモデルを使用する場合、コンポーネントの接続は非常に弱いため、構成とテストが簡単になります。
• 非同期メッセージベースの通信メカニズムは、タイマーと非常に友好的です。 アクターモデルでタイマーを遅延メッセージまたは定期メッセージとして使用するのは楽しいことです。
• C ++の初心者は、驚くほど高速にModel of Actorsに基づいてマルチスレッドプログラミングのトピックに入ります。 昨日の学生は、短時間で信頼できるマルチスレッドコードを書き始めます。

すくいとコーン

上記のボーナスは、タスクがアクターのモデルにうまく適合している場合にのみ得られます。 そして、それは常にうまくフィットするとは限りません。 したがって、注意が必要です。たとえば、重いコンピューティングタスクでアクターのモデルを取り上げると、喜びよりも痛みを感じることがあります。

アクターモデルが特定のサブジェクトエリアに適している場合は、適切なツールを使用することで人生を大幅に簡素化できます。

しかし、この場合、「熊手」または「落とし穴」のカテゴリに起因する可能性のあるもののアイデアを持っていることが非常に望ましいです。 次に、いくつかの熊手についてお話します。 これが誰かが私が今まで持っていたよりも少ないバンプを埋めるのに役立つことを願っています

エージェントの過負荷

最悪のサンゴ礁の1つは、俳優の過負荷の問題です。

過負荷は、エージェントがメッセージを処理する時間がないときに発生します。

たとえば、誰かが1秒間に3メッセージの速度でエージェントをロードし、エージェントが1秒間に2メッセージしか処理できないとします。 各サイクルのエージェントキューには、未処理のメッセージがもう1つあります。

エージェントが何らかの方法で過負荷から保護されていない場合、結果は悲しいものになります：着信メッセージキューが膨らみ、メモリが枯渇し、メモリ消費により作業が遅くなり、キューの成長がさらに速くなります。 その結果、アプリケーションのパフォーマンスが完全に低下します。

Model of Actorsで過負荷がそれほど怖いのはなぜですか？

メッセージの送信に基づく非同期相互作用では、フィードバックを実装する単純な可能性はありません（バックプレッシャーでもあります）。 つまり 送信側のエージェントは、受信側のエージェントのキューがどれだけいっぱいになっているかを知らず、受信側のエージェントが順番を変えるまで一時停止することはできません。 特に、送信エージェントと受信エージェントの両方が同じ作業スレッドで動作できるため、送信エージェントが「スリープ」すると、受信エージェントとともに共通の作業スレッドがブロックされます。

過負荷制御の複雑さは、特定のタスクに対して過負荷に対する保護の優れたメカニズムを強化する必要があることです。 過負荷が発生した場合、どこかで最新のメッセージをスローできます。 どこかで最も古いものを捨てる必要があります。 古いメッセージの場合は、別の処理戦略を選択する必要があります。

出口はどこですか？

私たち自身の経験から、2つのエージェントに基づくキャンペーンが非常にうまく機能していることがわかりました。コレクターとパフォーマーはそれぞれ異なるワークスレッドで動作します。 コレクターエージェントはメッセージを蓄積し、過負荷保護を提供します。 perfomerエージェントは、コレクタエージェントから次のメッセージバッチを定期的に要求します。 次のバッチが処理されると、実行エージェントは次のバッチを再度要求します。

しかし、悪いことは、これらすべてをアプリケーションプログラマが行う必要があるということです。 これらの目的のために、既製のツールセットを用意することをお勧めします。 そのため、SObjectizerに「 メッセージ制限 」と呼ばれる特別なメカニズムを組み込みました。これにより、プログラマーは、既成の簡単なポリシーを使用してエージェントを過負荷から保護できます。

コードでは次のようになります。

class collector : public so_5::agent_t { public : collector(context_t ctx, so_5::mbox_t quick_n_dirty) : so_5::agent_t(ctx //  get_status   . + limit_then_drop<get_status>(1) //      , //    ,  . + limit_then_redirect<request>(50, [quick_n_dirty]{ return quick_n_dirty; } ) //      ,   //    . + limit_then_abort<get_messages>(1)) ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し説明

「メッセージ制限」により、たとえば、エージェントのメッセージキューにget_statusタイプのメッセージを1つだけあれば十分であり、このタイプの残りのメッセージは簡単かつ簡単に破棄できることを指定できます。

 limit_then_drop<get_status>(1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キューにリクエストタイプのメッセージが50を超えないように指定し、このタイプの残りのメッセージを別の方法で処理する別のエージェントに送信する必要があります（たとえば、これが画像のサイズを変更するリクエストである場合は、より無作法にサイズを変更できます）しかし、はるかに高速）：

 limit_then_redirect<request>(50, [quick_n_dirty]{ return quick_n_dirty; } )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

場合によっては、キュー内の許可されたメッセージ数を超過することは、すべてが完全に悪いことを示しており、アプリケーション全体の動作を中断した方がよい場合があります。 たとえば、タイプget_messagesの2番目のメッセージがキューに表示され、最初のメッセージがまだ処理されていない場合、

明らかに何かが完全にうまくいかないので、std ::を呼び出して、再起動し、最初からやり直す必要があります。

 limit_then_abort<get_messages>(1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SObjectizerに追加されたメッセージの制限は、過負荷から保護するための完全なメカニズムではありません（そのようなメカニズムは特定のタスクのために研ぎ澄まされる必要があるため）が、単純な場合およびラピッドプロトタイピングでは、メッセージの制限は非常に成功しています。

メッセージ配信は信頼できません

一部の人にとっては、これは意外なことかもしれませんが、送信されたメッセージの受信者への配信は保証されていません。 つまり メッセージは途中で失われる可能性があります。 送信されたメッセージが受信エージェントに届かない主な理由はいくつかあります。

• 受信者はもはや存在しません。 つまり 送信時に存在していましたが、何とか消えました。
• 受信者はそこにいて、メッセージは彼に届いたが、受信者は現在の状態のメッセージを単に無視した。
• たとえば、「メッセージ制限」メカニズムのため、メッセージは受信者に届きません。

つまり、メッセージを非同期で誰かに送信する場合、そのメッセージが受信者に届くという確信はありません。

エージェントAがメッセージxをエージェントBに送信し、応答としてメッセージyを受信することを想定しているとします。 メッセージyがエージェントAに届くと、エージェントAは喜んで仕事を続けます。

ただし、メッセージxがエージェントBに到達せず、途中で失われた場合、エージェントAは応答メッセージyを無駄に待ちます。

メッセージの信頼性を忘れると、いくつかのメッセージを失っただけでアプリケーションが動作しなくなった状況に簡単に気づくことができます。 この例のように：エージェントAは、メッセージyを受信するまで作業を続行できません。

したがって、「メッセージの信頼性が低い場合、どのようにそれと一緒に暮らすか」という疑問が生じます。

どうする

メッセージの損失がパフォーマンスに影響しないように、エージェントの作業を設計する必要があります。 これを行うには、2つの簡単な方法があります。

1. タイムアウト後にメッセージを再送信します。 したがって、エージェントAがエージェントBから10秒以内にメッセージyを受信しなかった場合、エージェントAはメッセージxを再送信できます。 しかし！ ここで、メッセージの転送はエージェントの過負荷への直接のパスであることを理解する必要があります。 したがって、エージェントBは、 xメッセージで過負荷にならないように保護する必要があります。
2. 妥当な時間内に結果が得られなかった場合の操作のロールバック。 そのため、エージェントAがエージェントBから10秒以内にメッセージを受信しない場合、エージェントAはその側で以前に実行されたアクションをキャンセルできます。 または、現在の操作のステータスを「現在の結果不明」に設定して、次の操作の処理に進みます。

一見すると、非同期メッセージを介したやり取りが信頼できない場合、アクターモデルに基づいて開発されたアプリケーション自体も信頼できないように思われるかもしれません。 実際には、より興味深いことがわかります。アプリケーションの信頼性が向上するだけです（少なくとも私の意見では）。 これは、開発者が緊急事態を克服するためのいくつかのメカニズムをエージェントにすぐに強制するという事実によって説明されます。 そして、これらのメカニズムは、偶発事態が発生したときに機能します。

エラーコードと例外

このレーキをSObjectizerの開発者として正確に踏襲しました。 結果はユーザーに影響しますが。 実際、2002年にSObjectizerの最初のバージョンを作成したとき、エラーを報告するために例外を使用していませんでした。 代わりに、戻りコードが使用されました。

時間が経つにつれて、エラーコードは信頼できないことが判明しました。 ここでルールが機能しました：何かを忘れることができれば、それは忘れられます。 どこかでエラー処理をスキップするか、エラー処理をそのログのみに減らすだけで十分です。これは時間の経過とともに確実に横になります。 たとえば、アプリケーションはユーザー要求の処理を停止します。 その後、問題の痕跡をログのどこかに見つけることができます。 しかし、これは、問題がユーザーにすでに現れているという事実の後です。

そのため、2010年に新しいバージョンのSObjectizerの作成を開始し、以前のバージョンとの互換性を壊したとき、例外を使用してエラーを報告するように切り替えました。

私の意見では、これはアプリケーションの信頼性と品質にプラスの効果をもたらしました。 問題はもはや「飲み込まれ」なくなり、標準からの逸脱はすぐに顕著になります。

ほぼ100万の質問

エージェントBがエージェントAからのメッセージを処理する状況を想像してみましょう。このメッセージの処理中にエラーが発生すると、エージェントBはハンドラーから例外をスローします。 それをどうしますか？

この問題には2つの要素があります。

1. エージェントBは、SObjectizerが所有するコンテキストで実行されます。 また、SObjectizerは、エージェントBから飛び出した例外をどうするかわかりません。この例外は、すべてが非常に悪く、作業を続ける意味がないと言っているかもしれません。 または多分それはあなたが注意を払えないなんらかのナンセンスです。
2. エージェントBから送信された例外をキャッチして、エージェントAに配信しようとしても、次のことがわかります。
   
   
   • エージェントAはもはや存在しなくなり、既に存在しなくなっています。
   • エージェントAが存在する場合でも、エージェントBの問題に関する情報の受信に興味がない場合があります。
   • エージェントAがいて、エージェントBの問題に関する情報の受信に興味がある場合でも、何らかの理由で（たとえば、エージェントAが過負荷から保護されているため）この情報をエージェントAに配信しない場合があります。

それについてどうすればいいですか？

SObjectizerでは、エージェントから例外が発生した場合の処理​​を決定する特別なフラグを作成しました。 たとえば、アプリケーション全体を一度に強制終了するか、問題のあるエージェントを登録解除するか、例外を無視します。

例外がスローされたときにエージェントが登録解除するという事実により、Erlangのようにスーパーバイザーメカニズムの組織化が可能になります。 つまり、例外のために一部のエージェントが「落ちた」場合、スーパーバイザエージェントはそのようなドロップに対して「落ちた」エージェントに対応し、再起動することができます。

ここはアーランじゃない、ここは気候が違う

ここでのみ、C ++の場合、これはErlangや他の安全な言語ほどバラ色ではないことを示しています。 アーランでは、クラッシュさせるという原則は絶対的なものです。 そこでは、大まかに言って、ゼロによる除算も受け入れられません。 まあ、彼はErlangプロセスをゼロで割ろうとします。まあ、それは落ちます。Erlang仮想マシンはごみをきれいにし、スーパーバイザーは落ちたプロセスを再び作成します。 ただし、C ++では、ゼロで除算しようとすると、エラーが発生したエージェントだけでなく、アプリケーション全体が強制終了されます。

もう1つの重要なポイント：エージェントはC ++オブジェクトです。 アプリケーションから削除することに決めた場合は、有効期限が切れた他のオブジェクトと同様に、慎重に削除する必要があります。 つまり エージェントオブジェクトの場合、デストラクタが呼び出され、このデストラクタは正常に機能するはずです。

これは、エージェントオブジェクトが少なくとも例外の安全性の基本的な保証を提供する必要があることを意味します。 つまり、エージェントオブジェクトが例外をスローした場合、リソースリークやプログラム内の何かへの損傷は発生しません。

これは、C ++で「クラッシュさせる」という原則がErlangの場合とは大きく異なるという事実に自動的につながります。 そして、エージェントが例外に関して何らかの合理的な保証を提供することをすでに確認し始めている場合、エラーの結果をフレームワークに克服することに対する懸念をシフトする必要がないことがすぐに明らかになります。 これはエージェント自身が行うことができます。

これは、エージェントが自然にnothrow保証をサポートし始めるという事実につながります。 つまり 例外をまったくスローしないでください。 大まかに言って、何か深刻なことをするエージェントのメッセージハンドラーには、try-catchブロックが含まれています。 同時に、例外がエージェントから飛び出す場合（catchブロックで予期しない何かを意味する場合）、アプリケーション全体に何か問題があります。 この場合、問題のあるエージェントを1つではなく、アプリケーション全体を殺す必要があります。 継続的な正しい動作を保証することはできませんので。

したがって、モラル：C ++はErlangではなく、ErlangまたはC ++の他のプログラミング言語に適したエラー処理アプローチを転送する価値はありません。

---

これが最初の部分のすべてで、 ここに続きます 。