5

正しいルートをたどっているかどうかわからないので、スレッド管理の使用と、できればタスク並列ライブラリーの使用についてアドバイスを得たいと思っています。おそらく最善の方法は、私がやろうとしていることの概要を説明することです。

問題が与えられた場合、ヒューリスティック ベースのアルゴリズムを使用してソリューションを生成する必要があります。基本的なソリューションを計算することから始めます。この操作は並列化できないと思うので、心配する必要はありません。

初期ソリューションが生成されたら、n 個のスレッドをトリガーして、より良いソリューションを見つけようとします。これらのスレッドは、いくつかのことを行う必要があります。

  1. それらは、別の「最適化メトリック」で初期化する必要があります。言い換えれば、コード内に設定された優先レベルで、さまざまなものを最適化しようとしています。これは、それらがすべてわずかに異なる計算エンジンを実行することを意味します。TPLでこれができるかどうかはわかりません..
  2. スレッドの 1 つが、現在最もよく知られている解決策 (すべてのスレッドで共有する必要がある) よりも優れた解決策を見つけた場合、最適な解決策を更新し、他の多くのスレッドを強制的に再起動する必要があります (これも優先レベルによって異なります)。最適化指標の）。
  3. スレッド間で特定の計算を組み合わせたい場合もあります (たとえば、問題への特定のアプローチの確率の結合を維持します)。ただし、これはおそらくよりオプションです。
  4. システム全体は明らかにスレッドセーフである必要があり、可能な限り高速に実行したいと考えています。

自分のスレッドを管理してシャットダウンするなど、かなりの実装を試みましたが、かなり複雑になり始め、TPL の方が優れているのではないかと考えています。誰かが一般的なガイダンスを提供できるかどうか疑問に思っていますか?

ありがとう...

4

2 に答える 2

4

私は間違いなくTPLを見ます。問題を抽象化することができます。基礎となるスレッド モデルと wn スレッドの作成と管理に多くの時間を費やすのではなく、タスクとその動作とデータの共有について考えることができます。TPL を使用すると、スレッド プールに割り当てるタスクを作成できます。その後、TPL はプールを管理し、実行中のタスクの数を調整してパフォーマンスを最大化します。さまざまなハードウェア構成 (コア) でこれを行うため、開発が容易になり、異なるハードウェア間を移動するときに大幅な書き換えを必要としないアプリケーションになります。

特に状態の共有に関しては、まだ考えなければならないことがたくさんあります。通常、TPL は、スレッド化の経験が豊富な場合や、TPL があまり適していない特殊なケースのアプリケーションを使用している場合を除き、自分で作成するよりも優れたアプローチです。

1.別の「最適化メトリック」で初期化する必要があります。言い換えれば、コード内で設定された優先レベルで、さまざまなものを最適化しようとしています。これは、それらがすべてわずかに異なる計算エンジンを実行することを意味します。TPLでこれができるかどうかはわかりません..

これを行うには、タスクを作成し、それらに異なる開始条件を渡します。

2. スレッドの 1 つが、現在最もよく知られている解決策 (すべてのスレッドで共有する必要がある) よりも優れた解決策を見つけた場合、最適な解決策を更新し、他の多くのスレッドを強制的に再起動する必要があります (これは、スレッドによって異なります)。最適化メトリックの優先レベル)。

タスクをキャンセルして、新しいタスクを開始することができます。

3.スレッド全体で特定の計算を組み合わせたい場合もあります (たとえば、問題への特定のアプローチの確率の結合を維持します)。ただし、これはおそらくよりオプションです。

この要件を理解しているかどうかわかりません。

4.システム全体が明らかにスレッドセーフである必要があり、可能な限り高速に実行したいと考えています。

TPL を使用しても、タスク (スレッド) 間でデータを共有する場合でも、スレッドセーフな方法でこれを行う責任があります。ただし、TPL には、キュー、コレクション、バッグなどのスレッドセーフなクラスがいくつか付属しています。

その音からすると、これは投機的実行とワーク スティーリングが投入されたマスター/ワーカー パターンの変形です。このパターンやその他のパタ​​ーンの詳細については、http://parallelpatterns.codeplex.com/を参照してください。ページの下部にある Stephen Toub によるホワイト ペーパーには、追加の詳細も記載されています。

于 2010-04-26T20:16:03.697 に答える
0

これはどうやっても複雑になります。適切な同期コードを記述することは非常に困難です。そして、TPLはこれにはやり過ぎだと思います。

私が推奨するのは、座って問題を見て、それをホワイトボードに書き出して、可能な限り複雑さを取り除くことです。

たぶんこれが役立つでしょう... 最適化指標のキューと、最良の回答を持つ共有クラスを作成します。共有クラスをリーダー ライター ロックで保護し、キューをミューテックスまたはその他のロックで保護します。4 ～ 8 スレッド (CPU ごとに 1 つのスレッド、またはブロックが多い場合はそれ以上) を起動し、それらをループで実行します。キューからアイテムを削除して処理し、共有データをチェックして、アイテムがなくなるまで繰り返します。

3,000 スレッドを起動する誘惑に抵抗し、次のような競合状態に注意してください: 共有クラスのリーダー ロックをプルし、答えを確認してください。それがより良い答えであるとしましょう。リーダー ロックをドロップし、ライター ロックをプルします。共有クラスを更新します。ここでの問題は、ライターのロックを待っている間に別のスレッドがクラスを更新した可能性があり、ライターのロックを取得したら、チェックせずに「最良の」答えを吹き飛ばしてしまったことです。

楽しむ。

于 2010-04-26T15:25:11.697 に答える