問題タブ [actor]

膨大な量のタスクがあります。各タスクは 1 つのグループに属します。要件は、タスクの各グループが単一スレッドで実行されるのと同じように連続して実行され、スループットがマルチコア (またはマルチ CPU) 環境で最大化される必要があることです。注: タスクの数に比例する膨大な量のグループもあります。

単純な解決策は、ThreadPoolExecutor と同期 (またはロック) を使用することです。ただし、スレッドは互いにブロックし合い、スループットは最大化されません。

もっと良いアイデアはありますか？または、要件を満たすサードパーティのライブラリが存在しますか?

別の俳優の信号を待って、俳優を「スリープ状態」にしようとしています。私は次のようなことをしたい:

では、アクターが眠っているとき、他のメッセージはどうなるでしょうか? 彼らは失望しますか？私はそれらを失いたくない。これを修正する良い方法は何ですか?

Scala2.8は昨日発表されました。彼らはとりわけ「強化された俳優」を強調しています。

「デーモンスタイルのセマンティクスを持つアクター」とはどういう意味ですか。それについて詳しくはどこで確認できますか？

アクターとエージェントを比較するために、Scala（ソースはこちら）（Scala 2.8 RC7）とClojure（ソースはこちら）（Clojure 1.1）のリングネットワークトポロジのシミュレーションを作成しました。

Scalaバージョンはネットワーク内のノード数を100から1000000に増やすとほぼ一定のメッセージ交換レートを示しますが、Clojureバージョンはノード数の増加とともに減少するメッセージレートを示します。また、1回の実行中、Clojureバージョンのメッセージレートは時間の経過とともに低下します。

だから私はScalaの俳優がClojureのエージェントとどのように比較されるのか興味がありますか？エージェントは本質的にアクターよりも並行性が低いのですか、それともコードは非効率的に記述されていますか（オートボクシング？）？

PS：Scalaバージョンのメモリ使用量はノード数の増加に伴って大幅に増加しますが（100万ノードの場合は> 500 MB）、Clojureバージョンのメモリ使用量ははるかに少なくなります（100万ノードの場合は約100 MB）。

編集：

両方のバージョンは同じJVMで実行されており、すべてのJVM引数とアクターおよびエージェントの構成パラメーターがデフォルトとして設定されています。私のマシンでは、Scalaバージョンは1億から100万ノードで一貫して約5000メッセージ/秒のメッセージレートを提供しますが、Clojureバージョンは100ノードで60000メッセージ/秒で始まり、100万ノードで200メッセージ/秒に減少します。

編集2

私のClojureバージョンは非効率的に書かれていることがわかりました。nodesコレクションのタイプをからに変更するlistとvector、一貫した動作が表示されます。100ノードの場合は100000メッセージ/秒、100000ノードの場合は80000メッセージ/秒です。したがって、ClojureAgentはScalaActorsよりも高速であるように見えます。リンクされたソースも更新しました。

私はRemoteActorsで遊んでいます。RemoteActorをシャットダウンするとどうなるのだろうか。アクターは、R​​emoteActor.aliveおよびRemoteActor.registerで使用可能になりました。生きていると登録するという両方の逆を見つけることができません。

RemoteActorを適切にシャットダウンするにはどうすればよいですか？

アップデート

より明確にするために、私は「小さな」例を作成しました。次の2つのプログラムはどちらも終了せず、JVMは実行を継続します。ユーザーが作成したすべてのアクターとメインが終了します。

Aの出力は次のとおりです。

そしてBの場合：

デバッガーは、Aプログラムについて、次の4つの非デーモンスレッドがまだ稼働していると言います。

• PlainSocketImpl.socketAccept
• SocketInputStream.socketRead0
• ForkJoinScheduler.liftedTree1
• JavaVMを破棄します

val delegate = RemoteActor.select() を呼び出すときに決定論があるのだろうか。ネット経由でデリゲートを送信しているときに、プログラムが終了しないことに気付いたので、これを尋ねています。

デリゲートに依存する他の副作用はありますか?

RemoteActor.select が同じ引数に対して同じデリゲートを返す場合、ルールはありますか?

以下は、RemoteActor.select の問題を示すサンプル コードです。

Scala RemoteActorコードを書いているときに、いくつかの落とし穴に気づきました。

• 「java.lang.ClassNotFoundException」を回避するには、RemoteActor.classLoader = getClass（）。getClassLoader（）を設定する必要があります
• リンクは、「リモートアクターのプロキシ（より具体的には、プロキシデリゲート）が送信する前に、リモートアクターをバックアップするNetKernel（リモートでメッセージを転送する機能）が閉じることができる競合状態のため、常に機能するとは限りません。ローカル出口をリモートで示すメッセージ。」（ステファン・トゥ）
• RemoteActor.selectは、常に同じデリゲートを返すとは限りません（RemoteActor.select-結果は決定論的ですか？）
• ネットワーク経由でデリゲートを送信すると、アプリケーションが正常に終了しなくなります（RemoteActorの登録解除アクター）
• RemoteActor.alive（）およびRemoteActor.register（）がactの外部で使用されている場合、リモートアクターは終了しません。（マグナスの答えを参照してください）

プログラマーが知っておくべき他の落とし穴はありますか？

アクターモデルは、Gul Aghaのテクニカルレポート「アクター：分散システムでの同時計算のモデル」でうまく説明されています。

49ページで、彼は「become」コマンドについて説明しています。

「becomeX」を呼び出した後、アクターはすべてのメッセージを別のアクターのメールボックス（X）に転送します。

ただし、ErlangやScalaなどの言語でこれがどのように実装されているか（まったく実装されているか）はわかりません。手動でコーディングしなければならないのは何かですか？効率はどうですか？Aghaは、メッセージパッシングを使用したスタックの実装を示しています。ポップまたはプッシュが実行されるたびに、あるアクターにもう1つの転送リンクが追加されます...数十万の操作の後、そのような実装は、メッセージの転送に多くの時間を費やし、実際の作業を行わないことを期待します。優れた最適化が内部で実行されました。

だから私の質問は、Erlang、Scala（および他の言語のライブラリ）のような典型的なアクター言語で転送（または「なる」）をどのように実装するのかということです。

何かが欠けているかどうかわかりません。アクターをリモートにすると、メイン メソッドは終了しません。

問題を示すスニペットを次に示します。

約 2 日前に scala アクター フレームワークの学習を開始しました。アイデアを具体化するために、複数の同時接続を処理できる TCP ベースのエコー サーバーを実装することにしました。

エコー サーバーのコードは次のとおりです (エラー処理は含まれていません)。

基本的に、サーバーは「接続済み」および「切断済み」メッセージを処理するアクターです。これは、 serverSocketでaccept()メソッド (ブロッキング操作)を呼び出す匿名アクターにリッスンする接続を委任します。接続が到着すると、「Connected」メッセージを介してサーバーに通知し、新しく接続されたクライアントとの通信に使用するソケットを渡します。ConnectionHandlerクラスのインスタンスは、クライアントとの実際の通信を処理します。

接続ハンドラのコードは次のとおりです (いくつかのエラー処理が含まれています)。

接続ハンドラーは、ソケットの入力ストリームでreadLine()メソッド (ブロッキング操作)を呼び出すことによって、要求がソケットに送信されるのを待機する匿名アクターを使用します。リクエストが受信されると、「リクエスト」メッセージがハンドラーに送信され、ハンドラーは単にリクエストをクライアントにエコー バックします。ハンドラーまたは匿名アクターが基礎となるソケットで問題を経験した場合、ソケットは閉じられ、クライアントがサーバーから切断されたことを示す「切断」メッセージがエコー サーバーに送信されます。

そのため、エコー サーバーを起動して、接続を待機させることができます。次に、新しいターミナルを開き、telnet 経由でサーバーに接続できます。リクエストを送信でき、正しく応答します。ここで、別のターミナルを開いてサーバーに接続すると、サーバーは接続を登録しますが、この新しい接続の接続ハンドラーを開始できません。既存の接続のいずれかを介してメッセージを送信しても、すぐに応答がありません。ここが興味深い部分です。既存のクライアント接続を 1 つを除いてすべて終了し、クライアント X を開いたままにすると、クライアント X 経由で送信した要求に対するすべての応答が返されます。いくつかのテストを行った結果、 start()を呼び出しても、後続のクライアント接続でact()メソッドが呼び出されていないと結論付けました。接続ハンドラを作成するメソッド。

接続ハンドラでブロック操作を正しく処理していないと思います。以前の接続は、リクエストを待機している匿名のアクターがブロックされている接続ハンドラーによって処理されているため、このブロックされたアクターが他のアクター (接続ハンドラー) の起動を妨げていると考えています。

scala アクターを使用する場合、ブロック操作をどのように処理すればよいですか?

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