問題タブ [parallel-extensions]

Microsoft Reactive ExtensionsTask.Parallelのクラスを使用しています(私のアプリは 3.5 で実行されているため、.NET 4 のライブラリではなく、.NET 3.5 ライブラリ)。.NET ではすべて正常に動作しますが、Mono (Linux では 2.10.5) で実行すると、メソッドを呼び出すときに例外がスローされます。Parallel.For()

この例外をカバーしているリソースが Web 上に見つからなかったので、ちょっと行き詰まりました。助言がありますか？3.5 の Task Parallel ライブラリは Mono 上で動作しますか?

たとえば、クラス (2 つのパブリック プロパティ、1 つはタスク用、もう 1 つは URL 用) を作成し、インスタンスを返すことができます。しかし、この方法は他の方法と接続しました。

この問題の解決策はありますか？

異なるデータ オブジェクト間の差分を実行できるようにする「調整」ライブラリを実装しています。実装の一環として、比較するオブジェクト (ほとんどの場合 CSV ファイル) をデータテーブルに変換し、行の実際の値を比較する最後のステップと比較する特定のステップを実行しています。

行比較を行うために、以下のコードを使用しています。

デフォルトの DataRowComparer を使用する代わりに、カスタムの DataRowComparer を実装したいと考えていますが、これらのタスクは互いに独立しており、最後に比較で logical_AND または logical_OR のいずれかを実行するオプションを提供するため、すべての比較を並行して実行したいと考えています。タスク。

質問:

1. " " の実装はIEqualityComparer<TRow>where TRow : DataRow、行の並列比較を呼び出すのに十分ですか?

2. logical_AND については、最初の「false」で残りの比較を中止するのが理にかなっていると思います。これはできますか？

3. logical_OR の場合、スレッドで wait_All に似たものが必要になります。これはどのように実装できますか？

ThreadPool を使用して、ネストされた非同期ループの次の単純な実装を取り上げます。

現在、このパターンを使用することはありません (開始時にデッドロックが発生します) が、スレッドプールで発生する可能性のある特定のデッドロックを示しています。つまり、ブロックしているスレッドがプール全体を消費した後、ネストされたスレッドが完了するのを待っている間にブロックすることです。

これのネストされた Parallel.For バージョンを使用して、同様に有害な動作を生成する潜在的なリスクがあるかどうか疑問に思っています:

明らかに、スケジューリング メカニズムははるかに洗練されています (そして、このバージョンがデッドロックするのはまったく見たことがありません) が、潜在的なリスクがまだそこに潜んでいる可能性があるようです。Parallel.For が使用するプールを枯渇させて、ネストされたスレッドに依存することでデッドロックを作成することは理論的に可能ですか? つまり、Parallel.For が遅延後にスケジュールされたジョブのバック ポケットに保持するスレッドの数に制限はありますか?

私は現在.netc＃4.0で作業していますが、自分が書いたコードで問題が発生し、頭痛の種になっています。

System.Threading.Tasks.TaskFactoryクラスをSystem.Threading.Tasks.TaskSchedulerと組み合わせて使用​​して、コンソールアプリケーションで新しいスレッドを開始します。このスレッドの機能は、アイテムがキューに追加されているかどうかを確認することです。アイテムがキューに追加されると、それが処理されます。

したがって、キューには送信される電子メールが含まれ、電子メールがキューに追加されると、電子メールは複数のクライアントを介して送信されます。それぞれへの送信は並行して行われます。

この断続的な問題が発生し、新しいスレッドで次の例外が発生することがあります。

[System.Threading.ThreadAbortException] = {コードが最適化されているか、ネイティブフレームが呼び出しスタックの最上位にあるため、式を評価できません。}

デバッグ時に、スタック内のすべてのプロパティに「コードが最適化されているか、ネイティブフレームが呼び出しスタックの上にあるため、式を評価できません」と表示されているため、これ以上の情報を取得できません。

インターネットで解決策を探していると、これはresponse.redirectを実行するときに発生する問題であることがわかりましたが、コードではこれを実行していません。デバッグしようとすると、このエラーが発生する場所に一貫性がありません。以下は、ファクトリを作成して新しいスレッドを開始するために使用するコードです。

なぜこのエラーが発生するのかについてのポインタと、それを修正する方法についてのヒントはありますか？

書き込み操作が実行されているファイルの配列がありますParallel.ForEach。これを高速化するためにループを使用しています。

問題は、複数のスレッドがある場合、そのスレッドが不規則に動作することです。プログラムは、WAVファイルに250000ランダムバイトを10回書き込みます。これにより、約1.3秒の静的期間が発生します。何が起こっているのかというと、複数のスレッドでは、ファイルの大部分に静的なものはなく、Windowsはファイルが変更されたことを示しますが、オーディオコンテンツは変更されていません。他の問題は、一部のクリップに約6分の静的なものがあったことです。それに書き込まれることは不可能ですが、コードは各ファイルに2500000バイト（〜10.3秒）しか書き込みません。そのため、何らかの理由で間違ったファイルにバイトを書き込むため、静的なファイルがないものもあれば、ばかげた量のファイルもあります。静電気を見逃すことは不可能なので、私にはなれません。私は何かがうまくいかないことを知っています。

プログラムをマルチスレッド化する前はすべて正常に機能していたので、使用MaxDegreeofParallelism = 1してすべてが正常に機能したので、問題の原因は複数のスレッドであることがわかります。

編集：他の問題は、複数のスレッドで重要なデータを含むヘッダー部分に書き込むため、メディアプレーヤーがフォーマットを認識しないことです。これは複数のスレッドでのみ発生し、最初の500万バイトは無視しています。これで十分です。

編集：2更新されたコード。

私のコードが正しく機能しない原因となる複数のスレッドについて誰かが光を当てることができますか？

「ImpersonationOption.Required」を使用したWCFサービスがあります。並列処理を使用すると、なりすましが流れないように見えます。例えば：

偽装されたユーザーの番号と、アプリプールユーザーの番号を返します。なりすましを並列処理で機能させることはできますか？

一番、

マーク

アップデート：

これは、IISサービス側の実際のコードです。

numOfTests = 10を渡すと、10個のタスクが生成され、各タスクのWindowsIndentity名が返されます。私が得ているのは、「IIS APPPOOL.NET v4.0」の約70％と私です。

IDが常にParallel.ForEachになるように設定するにはどうすればよいですか？

ありがとう！

並列forループについて質問があります。私は次のコードを持っています：

今、私は並列関数を追加しようとしています：

問題は、時間を無駄にするのではなく、時間を節約したいということです。標準のforループでは約2分を計算しますが、並列のforループでは3分かかります。なんで？

ASP.NET アプリケーションで PLINQ を使用して、I/O バウンドおよび計算バウンド処理のスループットを向上させることを検討しています (たとえば、コレクションを反復して Web サービス呼び出しに使用し、地理座標距離を計算します)。

私の質問は、次のような操作を実行するParallel.ForEachと、他のリクエストの処理からスレッドが奪われることを心配する必要がありますか、それともスレッドの別のプールを使用するのでしょうか (I/O 完了ポートと呼ばれるものについて聞いたことがありますが、それがどのように機能するかはわかりません)議論に入る）？

私が取り組んでいるアプリケーションでは、毎秒数千の更新が受信されています。これらの更新をすぐに UI に反映するのは、パフォーマンスが過剰です。

次のコードでは、各更新を処理するために UI スレッドを呼び出し、ObservableCollection に新しいアイテムを追加する必要があるため、パフォーマンスが非常に悪くなります。これにより、CollectionChanged イベントがトリガーされます。

私がやろうとしているのは、パブリッシャーにアイテムを追加する機会を与えるために消費者を少し (つまり 50 ミリ秒) 待機させてから、これらの更新をチャンクで処理することです。

現在、私は次のコードを使用していますが、アイテムが消費される前にコレクション内に留まる時間を予測するのは難しいと思います。このアプローチが別のパフォーマンスのボトルネックを生み出すのではないかと心配しています。