問題タブ [queueuserworkitem]

QueueUserWorkItem() への呼び出しの前後で、プロファイラーで断続的なスパイクが発生します。毎秒約 20 件のジョブをキューに入れています。各ジョブの複雑さはほぼ同じです。ジョブの 95% は、QueueUserWorkItem の呼び出しに 0.01 ミリ秒未満を費やしています。しかし、一見ランダムに見える数秒ごとに、ジョブには 20 ～ 60 ミリ秒かかります。

スムーズなシミュレーションを構築しようとしていますが、バックグラウンド タスクをキューに入れるだけで、フレームレートが大幅に低下します。

これは、ジョブが実際に終了するのにかかる時間ではなく、単にジョブをキューに入れるのに費やされた時間です。これにはほとんど時間がかからないはずなので、これは非常にイライラします。

私が試したこと：

• 1 秒あたりのジョブ数を少なくすると、それに比例してヒッチが少なくなりますが、それでもヒッチが発生します。
• job.queued 変数へのすべてのアクセスに lock(obj) を配置する
• defaultThreadPool の代わりに SmartThreadPool を使用します。STP の QueueWorkItem() 内で問題が解決しない

デリゲートに渡すメッセージでラベルを更新する必要がある aspx Web ページがありますが、これを行うたびにラベルが更新されません。以下にいくつかのコードを示します。

default.aspx

default.aspx.cs (分離コード):

最後に、イベントとデリゲートが存在するクラス:

これで、メソッド DoEncrypt が QueueUserWorkItem に追加されるたびに、完全に実行され、すべてが正しく行われます。デバッグ中に、コード ビハインドのメソッド feedbackInfo が正しく呼び出されることに気付きました。

ThreadPool 内から feedbackInfo メソッドを 3 回呼び出すと、実際には 3 回呼び出されるため、このメソッドは機能すると思います。両方のラベルの Text プロパティに、以前に割り当てられた値が含まれるたびに。

したがって、唯一の問題は、ラベル テキスト プロパティが変更されるたびにページが変更されないことです。何か案は？

と の違いを理解しようとしていParralel.ForますThreadPool.QueueUserWorkItem。

ハードウェアとソフトウェア:

• Intel i5 (クアッドコア)
• ウィンドウズ 7 64 ビット 教授
• ドットネット 4.5

ケース 1 コード: ThreadPool

出力：

スレッド 10 を使用して 0 を完了 (45.871)
スレッド 11 を使用して 1 を完了 (45.875)
スレッド 12 を使用して 2 を完了 (45.875)
スレッド 13 (45.875) を使用して 3 を
完了

ケース 2 コード: Parallel.For

出力：

スレッド 10 を使用して 0 を完了 (16.923)
スレッド 11 を使用して 1 を完了 (16.925)
スレッド 12 を使用して 2 を完了 (16.925)
スレッド 13 (16.926) を使用して 3 を
完了

質問：

ケース 1 の結果から、アクティブなスレッドは 4 つだけのように見えます。その後、最初の空きスレッドを使用して最後のタスクを完了します。ケース 2 では、5 つのスレッドがすぐに専用になり、「同時に」実行されるようです。

QueueUserWorkItem のスレッド処理で、並列クラスのように 5 番目のスレッドが使用されないのはなぜですか?

(ThreadPool.GetAvailableThreads(...)1023 個のワーカー スレッドが使用可能であることを確認します)。

私は ThreadPool.QueueUserWorkItem で作業しようとしていますが、そのうちの 2 つを実行すると、次のようになります。

1 秒未満でスタックすることがあります。何か案は？

呼び出しの 1 つは、ゲームのカウントダウン タイマーです。

ThreadPool.QueueUserWorkItem(new WaitCallback(x=>initClock(0,0)));

次のコードで、パラメータ「s」は何を表していますか? メソッドで使用されていないため、「s」を省略できないので、() => ... のようなパラメーターのない匿名メソッドがありますか?

更新 1:

受け入れられた回答によると、匿名メソッドは、以下の ocd のような通常の WaitCallback デリゲート メソッドの単なる置き換えであり、QueueUserWorkItem がパラメーターとして必要とします。したがって、's' は ThreadProc メソッドのパラメーターであるため、オブジェクト型である必要があります。

スレッドプール内のスレッドの状態を確認することはできますか? 私たちのアプリケーションは、多くのスレッドを使用することがありますが、そのほとんどは ThreadPool.QueueUserWorkItem の呼び出しにかかっています。ただし、アプリケーションが実際に多くのことを行っていない場合、スレッド数は決して減少しません。最終的にこれらのスレッドは停止すると思っていたでしょう。

周りを読んで、すべてのタスクが完了したら一時停止状態に入る必要があり、再利用されない場合は最終的にウェイクアップして終了する必要があると思います。

アプリケーションは .Net Compact Framework v2 を使用しています。スレッドがスタックしている可能性がありますが、Visual Studio でアプリケーションを一時停止すると、スレッド ウィンドウには 7 ～ 8 スレッドしか表示されません。v2005 にバンドルされているリモート プロセス ビューアには、プロセスが 40 を超えるスレッドを使用していると表示されます。使用されるのを待っているのは、スレッドプールのスレッドだけだと思います。

ThreadPool 内の作業が完了し、スレッドがプールに解放されていることをテストするには、どのようなアプローチを使用できますか?

編集1

これは .NET Compact Framework のリモート パフォーマンス モニターから取得したもので、スレッド プールのスレッド数は 25 です。ただし、ビジュアル スタジオ自体で言ったように、25 スレッドではなく、約 7 または 8 しかありません。

System.Threading.ThreadPool.QueueUserWorkItem()を使用してタスクを実行しています。

アプリケーションを実行しているときに、大量のメモリを消費していることに気付き、タスク マネージャーを使用してダンプ ファイルを取得しました。調べてみると、次のスタックで多くのスレッドがスタックしていることがわかりました。

また

これらのスレッドがスタックしているのはなぜですか? 間違った API を使用していますか? スレッドを正しく管理していないのでしょうか。

マルチスレッドのソフトウェアがあります。ソース スレッドは、一連の並列タスク (各タスクにはいくつかの処理とサード パート API との対話が含まれます) を開始し、それらの一部またはすべてが完了するのを待ちます。

各スレッドは、作業を完了するのに 3 ～ 30 秒かかります。

(本番環境では) の呼び出しThreadPool.QueueUserWorkItemとスレッドの実際の開始の間に最大 10 秒の遅延が発生する可能性があることを発見したため、スレッドプールで使用可能なスレッドの供給が飽和状態になっていると考えられます。その制限に関するコメントについては、こちらを参照してください: System.Threading.ThreadPool.SetMaxThreads のデフォルト値

これらのさまざまな数のスレッドを追跡できるようにして、さまざまな変更を加えたら、何かを指して「ほら、すべてのスレッドを使い果たした問題を解決した」と言うことができるようにしたいと考えています。

この MSDN ページ: https://msdn.microsoft.com/en-us/library/ff650682.aspxは、この種のものを追跡するカウンターがないことを意味し、DIY カウンターの推奨される実装を提供するだけです。

一方、このページ: http://blogs.iis.net/mailant/new-worker-process-performance-counters-in-iis7はカウンターが存在すると言っていますか? 「Maximum Threads」、「Total Threads」、および「Active Threads」が関連するはずだと言っているようです。これらは次のことを意味していると思います。

• 「最大」: 新しいスレッドを作成する前に古いスレッドが終了するのを待機し始める前に、TP が作成できるスレッドの数。
• 「アクティブ」: 任意の時点で実際にプログラム コードを実行しているスレッドの数。
• "合計"： ？？これは「アクティブ」+「開始されたが外部リソースを待機しているスレッドの数」だったと思いますか? 私たちの場合はサードパーティの API ですが、一般的にはディスク IO や DB アクセスなどである可能性があります。

Perf Monitorを開いて、「新しいカウンターを追加」>「W3SVC_W3WP」>これら3つの特定のカウンターを選択>特定のプロセスを選択>「追加」>「OK」でこれらを確認しようとしました。

次に、Perf Monitor グラフは次のことを示しています。 最大 = 256 合計 = 16 アクティブ = 0 !?

それは…ありそうもない？カウンターを誤解しているか、Perf Monitor の構成を誤っていると思いますか?

次の試みは、プロセスのタスク マネージャーの「スレッド」列を調べることでした (IIS マネージャーから PID を介して正しい w3wp プロセスを識別します)。これは通常、100 ～ 150 のスレッドがあることを示していますが、実際にプロセスをスラッシングすると (実行中の API エンドポイントをスパムします)、256 を超える数を取得できます (ある時点で 264 で見ました)。

誰でもこれに光を当てることができますか？

基本的に私の質問は、ThreadPool.QueueUserWorkItemThreadPool のスレッドの可用性の状態を追跡するための最良の方法は何かということです。

Win32 関数を使用してワーカー アイテムとしてプライベート メンバー関数 (パブリックまたはプロテクトとして使用可能であってはなりません) を呼び出そうとしていますQueueUserWorkItem()。以前にこれを行ったことがあり、簡単だったことは知っていますが、今ではそのスニペットを見つけることができず、bind()ブードゥーを機能させることもできません. したがって、この質問の目的のために、クラスは次のとおりです。

内部UsefulPublicFunction()には次のように表示されます。

私が雑草に夢中になっているように見えるのは、次のpThreadStartRoutineようなものへの割り当てです。

PrivateWorkItemおそらく署名を次のように変更する必要があることを認識しています。

その変化があっても、喜びはありません。VS2015 は、私が使用している方法が本当に嫌いですbind()。

私の課題はpThreadStartRoutineどのように見えるべきですか？