問題タブ [actor-model]

Erlang アクター モデル、Groovy アクター、Scala アクター モデルなどのコンテキストでいくつかの場所で言及されているのを見てきました。これは何を指しているのでしょうか?

プレゼンテーション用に Actor Model について読んでいますが、デッドロックや競合状態などの多くの落とし穴を回避できるため、共有状態の並列プログラミングよりも優れていると誰もが主張しています。私は、この主張の詳細が何であるかを自問しています。これらの問題を回避する場合、どのようにそれを行うのでしょうか?

アクター モデルはいつ使用する必要がありますか?

もちろん、デッドロックのない環境を保証するものではありません。

アクター A は、B が A を待っている間、B からのメッセージを待つことができます。

また、アクターが次のタスクに移る前にメッセージが処理されたことを確認する必要がある場合、メッセージを送信し、単純なブロックではなく「メッセージが処理されました」というメッセージを待つ必要があります。

モデルの力は？

ええと、タイトルはほとんどそれです：もし私があなたの前に非技術者/私の母/ 12歳の男の子/コッカースパニエルを座って、俳優を彼らに説明するように頼んだら、どこから始めますか？私の修士のプロジェクトにはかなりの程度彼らが関わっているので、私は尋ねます、そして一日おきに誰かが私が何をしているのかを彼らに話すように私に頼みます。私がコースで他の人と話しているとき、それはそれほど悪くはありません-通常、概念は異質ですが理解できます-しかし最近、化学者である私のフラットメイトが私にそれを彼女に説明するように頼みました、そして私が苦労したと言うのはかなり巨大です控えめな表現。

技術的な土台ではなく、アイデアを伝えるような説明を探しています。それは比喩である可能性があり、正確である必要はありません。私が彼らと何をしているのかを彼らに理解させたいだけです。何か案は？

アクター メッセージ パッシング セマンティクスの忠実な実装は、不変型であっても、論理的な観点からメッセージ コンテンツがディープ コピーされることを意味します。アクター モデルの単純な実装では、メッセージ コンテンツのディープ コピーが依然として最大のボトルネックであるため、一部の実装 (例: Kilim) はゼロコピー メッセージ パッシングをサポートしています。

私の質問は、JVM のような共有メモリ プラットフォームでゼロコピー メッセージ パッシング ( Actor ライブラリ/フレームワークの一部として) をどのように実装するかです。不変のコンテンツを持つメッセージに対してのみ機能し、メッセージ参照の可視性は何らかの方法で制限する必要があると思います。しかし、Actor モデルの実装の背後にある「理論」を見つけるのに苦労しています。

アクターに関して行われたアクター モデルの実装のベンチマークを見てきました。たとえば、Akka アクターは非常に軽量 (アクターあたり 600 バイト) であり、何百万ものアクターを作成できます。ただし、メッセージ パッシング スループットに関してベンチマークが行われたのを見たことがありません。

たとえば、ある数のアクターが与えられた場合、アクター間で 1 秒間にいくつのメッセージをやり取りできるでしょうか?

そのようなパフォーマンス ベンチマークへのリンクを持っている人はいますか (メッセージ パッシング スループットに関して)?

Scala Actors は初めてです。私が構築しようとしているのは、それぞれが特定の http 呼び出しを実行し、定期的に情報を取得して永続化するいくつかのカートリッジを持つアプリケーションです。堅牢性が最も重要です。これまでのところ、これらは私が考えた方法です：

1. TimerTask を中心にアプリを構築し、Actor からカートリッジを拡張し、それら.actの を定期的に呼び出します (または、代わりにメッセージを送信する必要がありますか?違いは何ですか?)
2. アクターから拡張し、タイムアウトを使用して定期的に実行します。

誰かが違いに光を当てることができますか?

ゲームサーバー用のErlangの可能性について考えているところです。(ああ、私はErlangの専門家ではありません。ステージを考えているだけです) これは、ゲームシミュレーションにアクターモデルを使用することを意味します。もちろん、最大の魅力は、複数のノードに分散された同時実行性です。

私の現在の大きな疑問は、衝突検出のようなマルチアクターの相互作用をどのように行うべきかということです。（これはほんの一例です）

どのゲームでも衝突検出は本質的に必要ですが、アクター モデルの性質上、グローバルに同期された状態クエリとすべてのターゲティング アクターの更新が必要なため、効率的ではなく、意味がありません。また、同期を使用すると、Erlang のアクター モデルのすべての利点が無効になります。

もちろん、スペース パーティショニングを正しく使用すれば、一度に対象とするアクターを小さくすることができますが、これは単なる最適化であり、主要な答えではありません。それとも、これはこの質問に対する正しい答えですか? 相互作用するアクターの数を減らすことで同期の範囲を狭めますか?

私はscalaの初心者で、ペストリープロトコルを実装するためのscalaコードを書いています。プロトコル自体は問題ではありません。ノードがあり、各ノードには入力したいルーティング テーブルがあります。コードの一部は次のとおりです。

問題は、getMatchingNode への関数呼び出しが行われると、アクターが勝手に死んでしまうことです。「リスト」はすべてのノードのリストです。(ノード オブジェクトのリスト) また、この動作には一貫性がありません。getMatchingNode の呼び出しは、各アクター (10 ノード) に対して 15 回行う必要があります。しかし、デバッグ中に、アクターは getMatchingNode 関数を 1 回呼び出した後、または 3 ～ 4 回呼び出した後に自分自身を殺します。実行される scala ライブラリ コードは次のとおりです。

Eclipse は、このコードが getMatchingNode 関数の for ループから呼び出されたことを示しています。

奇妙なことに、ループが正常に動作する場合もあれば、アクターを殺す scala コードに移動する場合もあります。

コードの何が問題なのですか??

どんな助けでも大歓迎です。

私は現在、Scalaで使用するロギングメカニズムに取り組んでいますが、予期しない問題が発生し、実際に作業できなくなりました。機能をテストするために、簡単なメッセージパッシングリングを設定することを検討しています。リング内では、各ノードはScalaアクターの拡張であり、そのすぐ隣（前/次）を認識しています。

リングの構築は次のように行われ、パラメーター「ノード」はコントローラーアクターから渡されます。

これは私が望むように機能しているように見え、各ノードは正しいネイバーのペアを受け取ります。ノードクラスには、次のように設定されたサイズ2の配列があります。

すべてが順調ですが、（ノード0から）リングの周りに渡されるメッセージを導入すると、すべてのノードがそのringNeighbors配列に同じ値を持っていることがわかりました。これらの値は、ringBuilder（つまりノード8のネイバー）関数のループの最後の反復と一致しています。追加のメッセージパッシングは発生しないため、ノード配列内のインスタンスごとに、したがってリングごとにこれらの値がどのように変更されたかがわかりません。

私はまだScalaのロープを学んでおり、誤って単純なものを見落としていないことを願っています。