問題タブ [ccr]

CCRとDSSフレームワークモデルを含む、スケーラビリティと並行性に対するさまざまなアプローチの比較に興味があります。特にHadoopとErlangスタイルの同時実行性との比較に興味があります

ここに ccr の専門家がいるかどうかは不明ですが、とにかく試してみましょう。

コードに次の関数があります。

dq.EnqueueTimer(TimeSpan.FromMilliseconds(TIMEOUT), timeOutFn);

タイムアウト後に関数を呼び出します。ただし、多くの開いているソケットでこのタイマーが必要なので、パラメーター (または ID) をタイマー関数に渡したいと思います。

これどうやってやるの？

ありがとう

R

テキストファイルから数万行を解析し、オブジェクトにハイドレイトし、操作し、永続化するなど、長期にわたる一連の個別のタスクを実行します。

これをJavaで実装している場合、ファイル内の各行またはX行ごとのタスク（つまりチャンク）について、Executorに新しいタスクを追加する可能性があると思います。

私が使用している.Netについては、よくわかりません。ここではCCRが適切かもしれないと思うのですが、私はそれについて十分に精通していないので、この質問をします。

CCRはJavaエグゼキュータと同等の方法で機能できますか、それとも他に利用できるものはありますか？

ありがとう

Microsoft の Concurrency and Coordination Runtime は、デッドロックという重大な問題に直面していたプロジェクトを文字どおり救ったのです。それ以来、以前よりも軽量で高速に実行される結果を生成する非同期コーディングを必要とするほぼすべてのことに対して、ますます頻繁に使用するようになりました。正直なところ、マルチスレッド/マルチコア開発に対する私の考え方が変わったと言えます。私の個人的な CCR への愛にもかかわらず、Web 上では CCR をめぐる話題はほとんどないように思われ、誰かがその理由を教えてくれるかどうか疑問に思っていました。より良い代替手段はありますか、それとも MS からのプロモーションの欠如ですか、それとも人々は単に既存のツールに満足しているのでしょうか?

PortSet<ActualResult, Exception>複雑な一連のタスクがあるため、エラー処理を実装すると、try/catch ブロックや、小さなタスクごとにChoice レシーバーなどを使用するときに、コードがすぐに肥大化する可能性があります。

ありがたいことに、CCR は、タスクのグラフのより一般的な方法である因果関係で例外を処理するメカニズムを提供しているようです。典型的な例は次のようになります。

私の場合、CCR を使用してスキャッター/ギャザー シナリオを実装し、「ジョブ」を並列化されたタスクの束に分割する、コンピューティング集約型のアプリケーションがあります。(さらに、これらのジョブを複数同時に実行できます。) 1 つのタスクが失敗した場合、ジョブの残りのタスクをすべて停止したいが、他のジョブは停止したくない。(パズルのピースが欠けている場合、結果は役に立たないので、これに取り組み続けることは単に CPU 時間の無駄になります。)

問題は、停止を実装するための最良の方法は何かということです。

1つのアイデアは次のとおりです。

1. 単一のDispatcherインスタンスを作成し、アプリケーションの有効期間にわたって保持します。
2. DispatcherQueue「ジョブ」（タスクのグループ）ごとに新しいものを作成します。Causalityを作成した直後に を追加しDispatcherQueueます。
3. 例外キューのハンドラで、 を呼び出しSuspend()ますDispatcherQueue。
4. ディスパッチャ キューを破棄する前に、因果関係を取り除いてください。

この提案がベスト プラクティスとみなされるのか、それとも、そのような (おそらくかなり一般的な) シナリオに対処するためのより良いアプローチがあるのだろうかと思います。

Concurrency and Coordination Runtimeを使用しており、ドキュメントに記載されているものと同様のコードを記述しています。次の行はコンパイルに失敗します：

コンパイラは次のエラーメッセージを表示します。

ドキュメントは型引数でそのメソッドを使用しており、明らかに一般的であるため、これは誤解を招きます。

（私はここに私自身の答えを投稿するつもりです、それは私がそれを理解しているので奨励されています）

ポートとレシーバーを介して 15 の非同期操作を連鎖させています。これにより、スレッド間のメッセージング時間、特にタスクがデータをポートに投稿してから、新しいタスクが別のスレッドで同じデータの処理を開始するまでの時間に非常に懸念を抱くようになりました。各スレッドが開始時にアイドル状態であるという最良の状況を想定して、ストップ ウォッチ クラスを使用して、それぞれが 1 つのスレッドで最高の優先度で動作する 2 つの異なるディスパッチャからの時間を測定するテストを生成しました。

驚いたことに、私の開発リグは Windows 7 x64 を実行している Q6600 クアッド コア 2.4 Ghz コンピューターであり、私のテストでの平均コンテキスト スイッチ時間は 5.66 マイクロ秒で、標準偏差は 5.738 マイクロ秒で、最大値はほぼ 1.58 ミリ秒でした ( 282 倍!)。ストップウォッチの周波数は 427.7 ナノ秒なので、センサー ノイズからはまだ十分離れています。

私がやりたいことは、スレッド間のメッセージング時間を可能な限り短縮することです。同様に重要なことは、コンテキスト スイッチの標準偏差を減らすことです。Windows はリアルタイム OS ではなく、保証もありませんが、Windows スケジューラは公平なラウンド ロビンの優先度ベースのスケジュールであり、このテストの 2 つのスレッドは両方とも最高の優先度です (その必要がある唯一のスレッドは高い) したがって、スレッド上でコンテキスト スイッチが発生することはありません (1.58 ミリ秒の最大時間で明らかです... Windows の量子は 15.65 ミリ秒だと思いますか?) 私が考えることができる唯一のことは、OS 呼び出しのタイミングの変動です。スレッド間でメッセージを渡すために CCR によって使用されるロック メカニズムに。

他の誰かがスレッド間メッセージング時間を測定し、それを改善する方法について何か提案があれば教えてください。

私のテストのソースコードは次のとおりです。

Port.Post() [ref.: PortElement Instantiation in the CCR ]への呼び出しのオーバーヘッドを削減することに関する Microsoft CCR フォーラムの投稿を読みました。インターリーブ アービターで OptimizedSingleReissueReceiver モードでポートを使用するにはどうすればよいですか?

Interleave でこの PortMode を使用する次のコードを実装しました。

最初は問題ないように見えましたが、時々 NullReferenceException が発生することがあります (この例外は、ポートがまだレシーバーにバインドされていないことを示しています)。

Interleave 内で PortMode.OptimizedSingleReissueReceiver を使用する別の方法を知っている人はいますか?

あなた方の何人かがこれについていくつかの指針を与えることができることを願っています。

Webサービスやデータベースなどのリモートリソースを呼び出す必要があるコードを生成します。

このコードを考えてみましょう

50人の子供に対して、サービスに50回の呼び出しを行い、オーバーヘッドを50回取得します。私の実際の例では、これは簡単に100万回の呼び出しになり、すべてが這うようになります。

私がやりたいのは、呼び出し元のスレッド/タスクに対して透過的な方法でこれらの呼び出しをバッチ処理することです。したがって、サービスを直接呼び出す代わりに、これらの呼び出しをバッチ処理する中央キュー（「鉄道駅」）を呼び出します。

そのため、それを行うと、呼び出し元のタスクがブロックされます。次に、キューはX呼び出しが蓄積されるのを待ってから、要求のリストを使用してリモートサービスに1回呼び出します。

結果が来ると、このキューは戻り値を適切なタスクに返し、ブロックを解除します。呼び出し元のスレッドの場合、これはすべて非表示のままであり、別の関数呼び出しのように見えます。

これはできますか？これを可能にするプリミティブはTPLにありますか？

ちょっとCCRのような匂いがして、他の作業が完了するのを待っていると同時にたくさんのことが起こっています。

もちろん、このコードを書き直して、Parentクラスのリクエストのリストを作成してから、サービスを呼び出すこともできます。問題は、私の本当の問題では、このすべてのコードが生成されるということです。したがって、Child.RemoteCallの実装の「内部を調べる」必要があり、これはすべて、これまでよりもはるかに複雑になります。また、子はリモートオブジェクトなどのプロキシになる可能性があります。実行可能であれば非常に難しいので、この複雑さを分離したいと思います。

これが誰かに意味があることを願っています、そうでなければ私が詳しく説明することを私に知らせてください。