問題タブ [parallel-extensions]

現在、 Reactive Extensions for .Net(Rx)の一部である Parallel Extensions を使用しています。.Net 4 ベータ リリースでも利用できると思います。

1) 実際に使用されているスレッドの数を特定する方法はありますか? これはEnvironment.ProcessorCount（論理コアの数）に関連していると思いますが、これを確認したいと思います。

2) 使用するスレッド数を設定する方法はありますか? ParallelOptions.MaxDegreeOfParallelism有望に見えるプロパティがあることに気付きましたが、デフォルトで -1 (スレッド数に制限なし) に設定されているように見えます。また、渡されるのではなく、現在のアプリケーションに対してこれを 1 回設定できるかどうかもよくわかりません。Parallel.For()などへの各呼び出しに

配列または配列で動作できる並列化（マルチスレッド）ソートアルゴリズムの単純な実装を探していますList<T>。並列拡張機能を使用することもできますが、その部分は厳密には必要ありません。

編集：Frank Kruegerが良い答えを提供しますが、その例をLINQを使用しない例に変換したいと思います。また、Parallel.Do()に取って代わられたようParallel.Invoke()です。

ありがとう。

私はこれを機能させるために本当に一生懸命努力しましたが、運がありませんでした。2つの入力パラメーターを持つ関数を実行するために並列拡張を取得するにはどうすればよいですか？私はより新しいバージョンである3.5フレームワークのReactiveExtensionsを使用しています。

act（または関数ProcessOrder ）を実行するための拡張機能を取得する必要がありますが、何を試しても実行できません。

以前は次のことができました。

しかし、それはもうサポートされていません

問題

ここで説明するコードは F# で作成しましたが、.NET 4 フレームワークに基づいており、特に F# の特殊性に依存しているわけではありません (少なくともそう思われます!)。

ディスクにいくつかのデータがあり、ネットワークから更新して、最新バージョンをディスクに保存する必要があります。

問題は、loadAndSaveAndUpdateすべてのデータに対して、関数を何度も実行する必要があることです。

各ステップは

• いくらかのディスク IO、
• いくつかのデータクランチ、
• いくらかのネットワーク IO (多くの遅延が発生する可能性あり)、
• より多くのデータ処理、
• およびいくつかのディスク IO。

これをある程度並行して行うとよいのではないでしょうか。残念ながら、私の読み取り機能と解析機能はどれも「非同期ワークフロー対応」ではありません。

私が思いついた最初の（あまり良くない）解決策

タスク

私が最初にしたことは、セットアップしてTask[]それらすべてを開始することでした：

次に、CTRL + ESC を押して、使用しているスレッドの数を確認しました。15、17、...、35、...、170、... アプリケーションを強制終了するまで! 何かがうまくいかなかった。

平行

私はほとんど同じことをしましたが、使用Parallel.ForEach(...)して結果は同じでした: たくさんのスレッドとたくさんのスレッド。

機能するソリューション...一種の

次に、使用可能なタスクがなくなるまで、nスレッドのみを開始しTask.WaitAll(of them)、次にその他のスレッドを開始することにしました。n

これは機能しますが、問題は、たとえばn-1タスクの処理が完了すると、多くのネットワーク遅延のためにブロックを主張する最後のタスクを待機、待機、待機することです。これは良くない！

では、この問題にどのように対処しますか? 非同期ワークフロー (およびこの場合、非同期関数を適応させる方法)、並列拡張、奇妙な並列パターンなどを含むさまざまなソリューションを表示していただければ幸いです。

ありがとう。

Visual Studio 2010Beta2を使用しています。

Parallel.Forループでは、異なるパラメーター値を使用して同じメソッドを実行します。実行後、処理されたデータはデータベースに保存する必要があります。

しかし、異なるスレッドからの同じデータコンテキストでは作業できないという例外があります。

では、問題は、複数のスレッドからのデータコンテキストとSubmitChanges（）をどのように処理するかということです。

少なくとも.NET4.0のリリース以来、Microsoftは並列および非同期プログラミングのサポートに多大な努力を払ってきたようであり、これに関連する多くのAPIとライブラリが出現したようです。特に、最近は次のような派手な名前がどこでも絶えず言及されています。

• リアクティブフレームワーク、
• PLINQ（Parallel LINQ）、
• TPL（タスク並列ライブラリ）と
• 並列拡張。

現在、これらはすべてMicrosoft製品のようであり、.NETの非同期または並列プログラミングシナリオを対象としているようです。しかし、それらのそれぞれが実際に何であるか、そしてそれらが互いにどのように関連しているかは完全には明らかではありません。いくつかは実際には同じものかもしれません。

一言で言えば、誰もが何が何であるかについて記録を立てることができますか？

次の単純なコード パターンを検討してください。

Parallel Extensions(PE) を使用して並列化したい場合は、次のように for ループ構造を単純に置き換えることができます。

ただし、PE は、Foo が false であることが判明したアイテムのスレッドに作業を割り当てる不要な作業を実行します。したがって、ここでは中間ラッパー/フィルタリング IEnumerable が合理的なアプローチであると考えていました。同意しますか？もしそうなら、これを達成する最も簡単な方法は何ですか? (ところで、私は現在 C#2 を使用しているので、ラムダ式などを使用しない例が少なくとも 1 つあればありがたいです。)

並行して処理したい監視可能なコレクションがあり、フィルタリング中に処理された値を監視し、最後にフィルタリングされた値を受け取るハンドラーをサブスクライブします。

私のサンプルは構文的に正しく、正常にコンパイルされます。コードを実行するとWhere、フィルタリングを実行するステートメントが評価されます。ただし、サブスクリプションにはデータが届きません。を削除AsParallelして処理が通常どおりに行われるようにするIEnumerableと、データが通過し、すべてが期待どおりに機能します。

これが私のサンプルで、文字列に対していくつかの処理を行っています。

次の奇妙なことは、TakeWhile演算子を使用する場合です。これは、概念的にはWhereに似ていますが、ParallelQueryを観察すると期待どおりに機能します。

サブスクリプションにログコードを追加すると、データは変換まで受信されますが、ToObservable変換後は受信されないことが示されます。

4行目のラムダのブレークポイントはヒットしますが、6行目のラムダのブレークポイントはヒットしません。

なぜTakeWhileデータが加入者に届くのにWhere届かないのですか？

重要な場合は、.Net4.0Frameworkクライアントプロファイルを対象としたプロジェクトを使用してVisualStudio2010RCでコードを開発します。

更新： @Sergeysの回答に基づいて、フィルターの配置を作り直しましたWhere。次のコードは期待どおりに機能します。

processedStrings最初に最初のオブザーバブルを列挙可能に変換して並列化し、次にそれをオブザーバブルに変換して最終結果をサブスクライブする必要があるのは、まだ少し厄介です。

HttpWebRequest使用するタスクがあります

これは明らかに。で失敗する可能性がありWebExceptionます。呼び出し元に、応答をカプセル化する（またはカプセル化しない）ヘルパータイプであるTask<HttpResult>whereを返したいと思います。HttpResultこの場合、4xxまたは5xx応答も例外ではありません。

したがって、リクエストタスクに2つの継続を添付しました。1つはでTaskContinuationOptions OnlyOnRanToCompletion、もう1つはOnlyOnOnFaulted。そして、すべてをaでラップして、Task<HttpResult>継続が完了した1つの結果を取得します。

3つの子タスク（要求と2つの継続）のそれぞれは、オプションを使用して作成されAttachedToParentます。

ただし、呼び出し元が返された外部タスクを待機するAggregateExceptionと、要求が失敗した場合にスローされます。

WebException障害が発生した継続で、クライアントコードが結果を確認できるように観察したいと思います。on fault継続スローにを追加しますWaitが、これを回避するためのtry-catchは役に立ちません。また、プロパティを見ることもありません（Exception「Task.Exceptionプロパティを使用した例外の監視」セクションのヒントとして）。

フィルタリングするイベントハンドラーをインストールすることもできUnobservedTaskExceptionますが、イベントは障害のあるタスクへの直接リンクを提供しないため、これはアプリケーションのこの部分の外部で相互作用する可能性があり、大ハンマーがナットを割る場合です。

障害が発生したインスタンスを考えると、Task<T>「障害処理済み」としてフラグを立てる手段はありますか？

簡略化されたコード：

と：

（HandleWebRequestSuccess最終的には、応答の内容を取得するためにさらにタスクをスピンオフします...）

クライアントは、予期され、すでに処理されている障害が原因でタスクがスローされることなく、タスクを待機してからその結果を確認できる必要があります。