問題タブ [parallel-extensions]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
1272 参照

c# - Parallel Extensions を使用して優先度の低いスレッドでキューに入れられたアイテムを連続して処理する方法

.NET 4.0 Parallel Extensionsを使用して、長時間実行されるプロセスの結果を優先度の低いスレッドでシリアルに処理する最良の方法を知りたいです。

実行と結果の両方を提供する次のクラスがあります。

これらのステップを処理し、処理後に順番にファイルに保存するにはどうすればよいですか? RemotedService.DoSomeStuff()サーバーからの応答を待っている間にファイルに保存したいと思います。

ファイルへの書き込みは次のようになります。

頭に浮かぶ 1 つのオプションは、それらを に追加し、それらを処理QueueするTimerを用意することです。ただし、これはリモート呼び出しのダウンタイムを利用していません。

頭に浮かぶ別のオプションは、System.Threading.Tasks.Taskperを使用して各結果をファイルに非同期に書き込むことですStepが、それは結果が順番に保存されることを保証するものではなく、ファイルへの書き込みで競合が発生する可能性もあります。

0 投票する
1 に答える
4531 参照

c#-4.0 - 並列ブルートフォースアルゴリズム

そこで私はhttp://codahale.com/how-to-safely-store-a-password/#を見ていて、やや強力なデスクトップコンピューターでさまざまなハッシュをどれだけ速く強制できるのか知りたくなり、テストしたくなりました。

私が見たアルゴリズムのほとんどはシングルスレッドであり、これはc#4.0 Parallel.net/Plinq拡張機能と同時構造(ConcurrentBagやIProducerConsumerなど)を使用する上で非常に興味深い課題であることに気づきました。

したがって、私のタスクは次のとおりです。並列化を使用して、n-lengthとcharset [x]のパスワードの最も効率的でパフォーマンスの高いブルートフォースチェッカーを構築します。つまり、一致するものが見つかるまで、指定されたcharsetとlengthのすべての可能な文字列を生成します。少なくとも2つのコアと適度な量のRAMを想定します

私はそれを自分で回転させるつもりです、最高の男性/女性を勝ち取らせてください:)

編集

パフォーマンスをまだ比較せず、範囲と既知のパスワードの長さを制限せずに最初の試行

次の試み

ParallelEnumerableは、サイズがintに制限されているため、賢くはありませんでした。大きなパスワードの文字セットで長く保持できるとは思えませんが、すぐに少なくとも長い時間が必要になります。BigIntに移行するか、その後何らかの方法で分解を開始する必要があると思います。

0 投票する
5 に答える
902 参照

java - Java 並列プログラミング

マルチコア デスクトップで CPU 集中型の Java アプリケーションを並列化する必要がありますが、スレッド プログラミングにはあまり慣れていません。私はScalaを見ましたが、これは本当に時間がかかる新​​しい言語を学ぶことを意味します. Ateji PX Java 並列拡張機能も調べました。これは非常に使いやすいように見えますが、まだ評価する機会がありませんでした。誰もそれをお勧めしますか?他の提案を歓迎します。

よろしくお願いいたします。

明細書

0 投票する
2 に答える
4619 参照

c# - CorrelationManager.LogicalOperationStackはParallel.For、Tasks、Threadsなどと互換性がありますか

背景情報については、次の質問を参照してください。

タスク並列ライブラリのタスクはActivityIDにどのように影響しますか?

その質問は、タスクがTrace.CorrelationManager.ActivityIdにどのように影響するかを尋ねます。@Greg Samsonは、ActivityIdがタスクのコンテキストで信頼できることを示すテストプログラムで自分の質問に答えました。テストプログラムは、タスクデリゲートの最初にActivityIdを設定し、スリープして作業をシミュレートし、最後にActivityIdをチェックして、同じ値であること(つまり、別のスレッドによって変更されていないこと)を確認します。プログラムは正常に実行されます。

スレッド化、タスク、および並列操作のための他の「コンテキスト」オプションを調査しているときに(最終的にはロギングのコンテキストを改善するため)、Trace.CorrelationManager.LogicalOperationStackで奇妙な問題に遭遇しました(とにかく奇妙でした)。以下の彼の質問に対する私の「答え」をコピーしました。

私が遭遇した問題を適切に説明していると思います(Parallel.Forのコンテキストで使用すると、Trace.CorrelationManager.LogicalOperationStackが明らかに破損している(または何か)が、Parallel.For自体が論理演算で囲まれている場合のみ) 。

これが私の質問です:

  1. Trace.CorrelationManager.LogicalOperationStackはParallel.Forで使用できる必要がありますか?もしそうなら、Parallel.Forが開始されたときに論理演算がすでに有効になっている場合、それは違いを生むべきですか?

  2. Parallel.ForでLogicalOperationStackを使用する「正しい」方法はありますか?このサンプルプログラムを別の方法でコーディングして、「機能」させることはできますか?「動作する」とは、LogicalOperationStackには常に予想される数のエントリがあり、エントリ自体が予想されるエントリであることを意味します。

ThreadsとThreadPoolスレッドを使用していくつかの追加のテストを実行しましたが、同様の問題が発生したかどうかを確認するために、戻ってそれらのテストを再試行する必要があります。

Task / ParallelスレッドとThreadPoolスレッドは、親スレッドからTrace.CorrelationManager.ActivityIdとTrace.CorrelationManager.LogicalOperationStackの値を「継承」しているように見えます。これらの値は、(SetDataではなく) CallContextのLogicalSetDataメソッドを使用してCorrelationManagerによって格納されるため、これは予想されます。

繰り返しになりますが、この質問に戻って、以下に投稿した「回答」の元のコンテキストを取得してください。

タスク並列ライブラリのタスクはActivityIDにどのように影響しますか?

MicrosoftのParallelExtensionsフォーラムで、この同様の質問(これまでのところ回答されていません)も参照してください。

http://social.msdn.microsoft.com/Forums/en-US/parallelextensions/thread/7c5c3051-133b-4814-9db0-fc0039b4f9d9

[貼り付けを開始]

これは実際にはあなたの質問に対する答えではないので、私の投稿を答えとして許してください。ただし、CorrelationManagerの動作やスレッド/タスクなどを扱っているため、あなたの質問に関連しています。私は、CorrelationManager LogicalOperationStack(およびStartLogicalOperation/StopLogicalOperationメソッド)を使用して、マルチスレッドシナリオで追加のコンテキストを提供することを検討してきました。

私はあなたの例を取り上げ、Parallel.Forを使用して並行して作業を実行する機能を追加するために少し変更しました。また、私はStartLogicalOperation/StopLogicalOperation(内部的に)ブラケットに使用しDoLongRunningWorkます。概念的にDoLongRunningWorkは、実行されるたびに次のようなことを行います。

これらの論理演算を(多かれ少なかれそのまま)コードに追加すると、すべての論理演算が同期されたままになることがわかりました(常にスタック上の予想される演算数とスタック上の演算の値は常に次のようになります)期待される)。

私自身のテストのいくつかでは、これが常に当てはまるとは限らないことがわかりました。論理演算スタックが「破損」していました。私が思いついた最も良い説明は、「子」スレッドが終了するときにCallContext情報を「親」スレッドコンテキストに「マージ」すると、「古い」子スレッドコンテキスト情報(論理操作)が「別の兄弟の子スレッドによって継承されました」。

この問題は、Parallel.Forが明らかにメインスレッド(少なくともサンプルコードでは、記述されているとおり)を「ワーカースレッド」(または並列ドメインで呼び出されるもの)の1つとして使用しているという事実に関連している可能性があります。DoLongRunningWorkが実行されるたびに、新しい論理操作が開始(開始時)および停止(終了時)されます(つまり、LogicalOperationStackにプッシュされてポップバックされます)。メインスレッドですでに論理演算が有効になっていて、DoLongRunningWorkがメインスレッドで実行されている場合、新しい論理演算が開始されるため、メインスレッドのLogicalOperationStackには2つの演算があります。DoLongRunningWorkの後続の実行(DoLongRunningWorkのこの「反復」がメインスレッドで実行されている限り)は、(明らかに)メインスレッドを継承します。

私の例では、LogicalOperationStackの動作が、変更したバージョンの例と異なる理由を理解するのに長い時間がかかりました。最後に、私のコードではプログラム全体を論理演算で囲んでいたのに対し、テストプログラムの修正バージョンではそうではなかったことがわかりました。これは、私のテストプログラムでは、「作業」が実行されるたびに(DoLongRunningWorkに類似)、すでに論理演算が有効になっていることを意味します。テストプログラムの修正バージョンでは、プログラム全体を論理演算で囲んでいませんでした。

したがって、プログラム全体を論理演算で囲むようにテストプログラムを変更したとき、およびParallel.Forを使用している場合は、まったく同じ問題が発生しました。

上記の概念モデルを使用すると、これは正常に実行されます。

明らかに同期していないLogicalOperationStackが原因で、これは最終的にアサートされますが、次のようになります。

これが私のサンプルプログラムです。これは、ActivityIdとLogicalOperationStackを操作するDoLongRunningWorkメソッドがあるという点であなたのものと似ています。DoLongRunningWorkのキックには2つのフレーバーがあります。1つのフレーバーはParallel.Forを使用するタスクを使用します。各フレーバーは、並列化された操作全体が論理操作で囲まれるかどうかに関係なく実行することもできます。したがって、並列操作を実行するには、合計4つの方法があります。それぞれを試すには、目的の「Use ...」メソッドのコメントを解除し、再コンパイルして実行します。 UseTasks、、UseTasks(true)およびUseParallelForすべてが完了するまで実行する必要があります。 UseParallelFor(true)LogicalOperationStackには予想される数のエントリがないため、ある時点でアサートされます。

LogicalOperationStackをParallel.For(および/または他のスレッド/タスク構造)で使用できるかどうか、またはどのように使用できるかというこの問題全体は、おそらく独自の質問に値します。多分私は質問を投稿します。それまでの間、これについて何か考えがあるかどうか疑問に思います(または、ActivityIdは安全であると思われるため、LogicalOperationStackの使用を検討したかどうか疑問に思います)。

[貼り付け終了]

誰かがこの問題について何か考えを持っていますか?

0 投票する
2 に答える
3048 参照

c# - Parallel.ForEachを使用するときに進行状況を送信する方法

各レコードをファイルに書き込めるように、DataTableでParallel.ForEachを使用することを計画しています。

処理されたレコードのパーセンテージ/数をユーザーに通知するにはどうすればよいですか。

通常、Backgroundワーカーを使用すると、ProgressChangedイベントが発生し、実行された作業の割合がユーザーに通知されます。Parallel.ForEachまたはMultipleタスクを使用してこれをどのように達成できますか?

ありがとう、バニー

0 投票する
2 に答える
840 参照

c# - Parallel Extensions または Parallel LINQ を LINQ Take で使用する

約500万行のデータベースがあります。データベース用の XML 文字列を生成してサービスにプッシュしようとしています。これを一度に 1 つずつ行う代わりに、サービスは一度に 1000 レコードの取得をサポートします。現時点では、これは非常に遅く、1000 レコードあたり 10 秒以上かかります (データベースへの書き込みとサービスへのアップロードを含む)。

次のコードを機能させようとしましたが、失敗しました...試してみるとクラッシュします。何か案は?

インデックスが範囲外であることを示すクラッシュが発生します。が 500 万の場合left、ループ内の数は 5000 を超えないようにする必要があります。これに 1000 を掛けても、500 万を超えることはありません。少しの間は機能し、その後失敗してもかまいませんが、SQL クエリの後で失敗するだけです。

0 投票する
2 に答える
905 参照

c# - Parallel.For から結果を取得する

戻るのに時間がかかる Web サービスを呼び出すために使用することを検討してParallel.Forいますが、同時に何度も呼び出すことができ、1 回の呼び出しよりもそれほど長くはかからないことがわかっています。

そのために、私は Parallel.For を試しており、これがどのように機能するかについて自分のアイデアを確認したいと思っています。アプリケーションを台無しにしたくないので、私はおそらく少し慎重すぎると思います。また、このルートに進む場合、アプリケーション チーム全体が、並列コードにアクセスするときに何をする必要があるかを確実に認識できるようにしたいと考えています。

とにかく、これが私の現在の作業と理解です。

は、指定された日付範囲 ( + )AvailServiceの空室状況を取得します。プロパティの識別子です。startDatenumNightscode

最初に正しいサイズの結果配列を設定し、空のスロットをたくさん用意しました。

次に、並行してサービスを呼び出します。サービスが新しいHotelAvailオブジェクトを作成し、それを配列の正しい位置に配置します。

すべてが完了したら、配列を返します。この時点で完全に設定されているはずです。空白があってはなりません。このサービスは、システム状態の他の部分には影響しません。Web サービス呼び出しを作成して呼び出し、結果オブジェクトを返すだけです。

私が見ていないこれに関する問題はありますか?

上で述べたように、私は慎重すぎるかもしれませんが、若くて活気に満ちた時代にマルチスレッド コードを書くことに疲れていたので、同じ過ちを繰り返したくありません。

また、このコードは最終的に ASP.NET アプリケーションになります。マルチスレッドコードについて多くの不満があったことをぼんやりと思い出します。そこで発生する可能性のある追加の問題はありますか?

0 投票する
2 に答える
3113 参照

c# - マルチレベルの ConcurrentDictionary はまだスレッドセーフですか?

次のように定義された 4 つのレベルのデータ構造があります。

全体が、スレッドセーフも維持するクラスにカプセル化されています。現在、データの読み取り/操作中にコレクション全体をロックするだけです (読み取りは、書き込みよりも桁違いに一般的です)。

DictionaryConcurrentDictionaryListで置き換えようと考えていましたConcurrentBag(そのアイテムは注文する必要はありません)。

そうする場合、ロックを解除して、並行コレクションが正しく機能することを確認できますか?

0 投票する
4 に答える
144050 参照

c# - Parallel.ForEachとTask.Factory.StartNew

以下のコードスニペットの違いは何ですか?両方ともスレッドプールスレッドを使用しませんか?

たとえば、コレクション内のアイテムごとに関数を呼び出したい場合、

0 投票する
6 に答える
16332 参照

c# - リストスレッドセーフ

私は以下のコードを使用しています

上記のコードスレッドは安全ですか?処理されたリストが破損する可能性はありますか?または、追加する前にロックを使用する必要がありますか?

ありがとう。