0

ThreadPool.SetMinThreads()私は、999 項目の同時辞書を作成し、メソッドを使用して 50 のスレッドを起動する単純なアプリケーションを作成しました。次に、999 個の辞書エントリをループ処理し、データベース内のレコードを更新して、エントリが処理されたことを示すフラグを立てます。

アプリケーションを実行すると、スレッドが開始されたことを確認できます。その後、SQL クエリを実行して、レコードが更新されていることを確認できます。これまでのところ、これらはすべてかなりうまく機能しています。初期スレッドのいくつかが終了すると、スレッドの次のバッチが開始されます (これはまさに私がやりたいことです)。データベース内のレコードがまだ更新されていることを確認でき、アプリケーションが期待どおりに動作していることがわかります。新しいスレッドが作成されているのをまだ確認できますが、デッドロックが発生します。デッドロックを見ると、開始された最初の 50 スレッドの 1 つからのものです。これが私の質問の出番です。

6Gb RAM を搭載した 3Ghz デュアル コア プロセッサでアプリケーションを実行しています。私の SQL Server インスタンスも同じマシンで実行されていますが、これが問題になるとは思いもしませんでした。アプリは概念実証ですが、開発環境で 50 スレッドを実行できないことは有望に見えません。実稼働環境では、アプリケーションと同様に、SQL インスタンスが別のマシン上にあることを私は知っています。何か案は？

4

2 に答える 2

1

複数のスレッドから同じテーブルを更新すると、データベースのデッドロックが発生する可能性があります。失敗したSQLステートメントを再実行するか、ステートメントのロックレベルを変更する必要があるようです。これは、ステートメント自体のロックヒントを使用して実行できます。

于 2011-10-23T16:09:48.623 に答える
0

典型的な Windows のインストールでは、簡単に 900 のスレッドが実行されます。Taskmgr.exe の [パフォーマンス] タブを確認してください。それらの大部分は、何かが起こるのを待ってブロックされます. さらに 50 を追加しても、それほどへこみはありません。多くのコードを実行することはなく、常に dbase サーバーがその仕事をするのを待っています。そのため、多くのスレッドを開始することはあまり役に立ちません。コードのパフォーマンスは、dbase エンジンがクエリを実行できる速度によって完全に抑制されます。CPU 負荷が 100% でな​​い場合は、Taskmgr.exe から簡単にわかります。スレッドを追加しても効果はありません。

いいえ、デッドロックの原因はコードであり、リソースの不足ではありません。また、50 個のボールを 1 つも落とさずに空中に維持することは、非常に難しいプログラミングの問題です。Debug + Windows + Threads デバッグ ウィンドウを使用して、スレッドが進行していない理由を把握します。

于 2011-10-23T15:54:47.333 に答える