18

私は最近、Go Concurrency patterns に関する Google IO トークを見て楽しんでいました。

同時実行性に対する Go のアプローチ (グラルーチン、チャネルを介した通信) は明らかに Clojure とは異なりますが (不変性、管理された参照、STM)、Clojure コンテキストの状況によっては、Go のアプローチが依然として有用であるように思われました。

Clojure または Java for Go の同時実行プリミティブ (おそらくライブラリ) には、特に次のようなものがあります。

  • channelリーダーとライターが両端で使用可能になるまでブロックするようなオブジェクト
  • select複数のチャネルで結果を待つことができる のような構造

PS Clojure から簡単に使用できるので、Java ソリューションに完全に満足しています。

UPDATE質問が最初に尋ねられたので、Clojureには、このすべての機能などを提供するcore.asyncが含まれるようになりました。

4

8 に答える 8

3

リーダーとライターが両端で使用可能になるまでブロックするチャネルのようなオブジェクト

これは少し紛らわしいです。「書き込みの場合はリーダーが使用可能になるまで、または読み取りの場合はライターが使用可能になるまでブロックする」という意味ですか？コンストラクトではなくスレッドに代わって話しているのですが、コンストラクトはスレッドだけをブロックすることはできません。（混乱を避けるために、構成はスレッドにブロックするように指示します）。

私の仮定が正しい場合、（標準のJavaでは）2つのオプションがあります。

  1. SynchronousQueue
  2. TransferQueue（これはバッファチャネルとしても使用できますが）

複数のチャネルで結果を待つことができるselectのような構造

私の知る限り、真のselectような構造はありません。最も近いのはExecutorCompletionServiceで、次に送信された利用可能なタスクが完了すると返されます。

于 2012-07-03T15:27:35.507 に答える
3

私は最近go-lightlyを作成しました。これは、Go の同時実行コンストラクトを使用したプログラミングをサポートする Clojure ライブラリであり、その並行プログラミング スタイルにいくつかの Clojure イディオムを取り入れています。

Go 同時実行プログラミングのコア構造は次のとおりです。

  1. ルーチンに行く
  2. 同期 (ブロッキング) チャネル
  3. 限定された、ほとんどが非同期の (ノンブロッキング) チャネル
  4. 複数のselectチャネルから次に利用可能なメッセージを読み取るオペレーター
  5. チャネルの読み取り/書き込み/選択のタイムアウト操作

go-lightly ライブラリには、これらすべての機能があり、Java と Clojure で利用可能な機能の上に構築されています。True Go ルーチンは、スレッドをその存続期間全体にわたって完全に使用するのではなく、スレッドに多重化されます。go-lightly では、Clojure future マクロの上に go ルーチンを構築しているため、これが JVM 上の Go モデルの最も弱い部分です。

私はラミナを使用してみましたが、制限されたチャネル (いくつかのシナリオで必要になる可能性があり、Go バッファーチャネルモデルの一部です) がなく、私が知る限り、メッセージをチャネル。これは、Go 同時実行モデルの重要な機能です。

go-lightly ライブラリを使用した多くの例を git リポジトリに含めました。そのほとんどは、Rob Pike が過去 2 年間の講演で示した例に基づいています。

JCSP の上に Clojure ライブラリを構築するのは興味深いことですが、まだ調査していません。

于 2013-01-30T04:12:00.413 に答える
2

Go について何も知らなくても、Lamina を見て、探しているものに適合するかどうかを確認してください https://github.com/ztellman/lamina

于 2012-07-02T18:43:02.397 に答える
0

Joxaを見てください。これは、Erlang 仮想マシンを対象とする Lisp の Clojure に似た方言です。

また、Erlangは 1000 バイト未満の軽量プロセスで知られています。

また、 Erjangにも多少関連があり、興味があるかもしれません。これは、JVM 上の Erlang 仮想マシンの実装です。

したがって、理論的には Joxa を BEAM にコンパイルしてから、JVM で実行することができます。私がそれをお勧めするわけではありません:-)。

于 2012-07-02T22:31:11.820 に答える
0

Occam/transputer アルゴリズムに基づくJCSPを強くお勧めします。この API 実装の重要な部分は、正式なメソッドと正式な証明者アルゴリズムを使用して正確性がチェックされているため、可能な限り信頼できます (Alternative クラスは、この点で主要な成果です)。

JCSP は非常に優れていますが、JVM によって課せられる制限、特にスレッドの高コストが欠点として残っています。Go や Occam では、スレッド数は数百万になりますが、JVM ではそうではありません。

于 2012-12-18T22:21:02.457 に答える