10

「メッセージパッシング」には2つの方法があることに気づきました。1つはErlangの使用を確認し、もう1つはStacklessPythonからのものです。私が理解していることから、ここに違いがあります

Erlangスタイル-メッセージが送信され、受信プロセスのメールボックスにキューに入れられます。そこから、FIFOベースで削除されます。最初のプロセスがメッセージを送信すると、続行できます。

Pythonスタイル-プロセスAはプロセスBに送信するためにキューに入れられます。Bは現在他のアクションを実行しているため、Bが受信する準備ができるまでAはフリーズします。Bが読み取りチャネルを開くと、Aはデータを送信し、両方とも続行します。

これで、Erlangメソッドの長所は、ブロックされたプロセスがないことです。Bが受信できない場合でも、Aは続行できます。しかし、私が書いたいくつかのプログラムでは、メッセージの流入が流出よりも多いため、Erlangメッセージボックスが数百（または数千）のメッセージでいっぱいになる可能性があることに気づきました。

今、私はどちらのフレームワーク/言語でも大きなプログラムを書いたことがないので、あなたの経験はこれであるのだろうかと思います。

はい、私はこれが抽象的なことを知っていますが、私はかなり抽象的な答えも探しています。

4

2 に答える 2

8

Erlangプログラミングでの私の経験では、高いメッセージングレート（つまり、コンシューマーよりも高速なプロデューサー）が必要な場合は、独自のフロー制御を追加します。簡単なシナリオ

  • コンシューマーは、メッセージを送信し、ackを待ってから、繰り返します。
  • プロデューサーは、メッセージを待ち、メッセージを受信して​​処理したときにackを送信してから、繰り返します。

それを逆にすることもできます。プロデューサーは、コンシューマーが来て、次に利用可能なN個のメッセージを取得するのを待ちます。

これらのアプローチやその他のフロー制御は機能の背後に隠すことができます。最初のアプローチは、 OTP動作プロセスgen_server:call/2,3に対してすでにほとんど利用可能です。gen_server

レイテンシーが高い場合は、コンピューター間のメッセージング時に同期を避けたいと思うかもしれないので、非同期メッセージングは​​Erlangのように優れたアプローチだと思います。次に、フロー制御を実装するための巧妙な方法を作成できます。たとえば、プロデューサーが送信したN個のメッセージごとにコンシューマーからの確認応答を要求するか、特別な「これを受信したらpingしてください」というメッセージを時々送信して、ping時間をカウントします。

于 2010-02-10T21:29:16.177 に答える
4

大まかに言えば、これは制限のないキューと制限のあるキューです。スタックレスチャネルは、サイズが0のキューの特殊なケースと見なすことができます。

制限されたキューはデッドロックする傾向があります。キューがいっぱいの状態で、互いにメッセージを送信しようとしている2つのスレッド/プロセス。

制限のないキューには、より微妙な障害があります。あなたが言ったように、大きなメールボックスは待ち時間の要件を満たしません。十分に行くと、最終的にはオーバーフローします。無限メモリのようなものはないので、実際には、いっぱいになるとプロセスを中止する巨大な制限のある制限されたキューにすぎません。

どちらがベストですか？それは言うのが難しいです。ここに簡単な答えはありません。

于 2010-02-10T20:34:40.250 に答える