問題タブ [manualresetevent]

接続をリッスンすることから始まるプログラムがあります。私は、サーバーが接続を受け入れ、その個々の接続を処理のためにユーザー クラスに渡すパターンを実装したいと考えていました。将来のパケット受信とデータの処理です。

クラスの非同期使用がSocket怖くないことがわかる前に、同期パターンで問題が発生しました。しかし、その後、さらに問題が発生しました。は非同期であるため、while (true)ループ内でBeginAccept()は、プログラムは常にこのループを移動し、最終的にOutOfMemoryException. 接続をリッスンし、すぐにその接続の責任を他のクラスに引き渡すものが必要でした。

そこで、Microsoft の例を読んで、ManualResetEvent. ループが再びリッスンを開始する準備ができたときを実際に指定できました! しかし、スタック オーバーフローに関するいくつかの質問を読んだ後、私は混乱してしまいました。

私の心配は、接続を非同期に受け入れたとしても、ループに再び入るときに新しい接続をリッスンしようとしている間、プログラム全体がブロックされることです。複数のユーザーを扱っている場合、これは理想的ではありません。

私は非同期 I/O の世界に非常に慣れていないので、私の語彙やフレーズの誤用についての最も怒っているコメントでも感謝します。

コード：

要件は次のとおりです。処理するアイテムはグローバル キューに格納されます。いくつかのハンドラ スレッドは、グローバル キューからアイテムを取得して処理します。プロデューサー スレッドはアイテムを継続的かつ迅速にグローバル キューに追加します(すべてのディーラー スレッドの処理速度よりもはるかに高速です。また、ハンドラー スレッドは計算集約型です。最高のパフォーマンスは、CPU を完全に使用することです)。そのため、もう 1 つのcountKeeping スレッドを使用して、 BOTTOMからTOPまでのように、キューの長さを特定の範囲に維持します (メモリを使いすぎないようにするため)。

ManualResetEvent「キューに追加可能」ステータスの変更に対処するために使用します。グローバルキューは

ハンドラスレッドは

プロデューサ スレッドは AddToQueue() 関数を呼び出してアイテムを mQueue に追加します。

countKeeping スレッドは主に次のようなものです

ここで問題が発生します。
BOTTOM と TOP を小さい数値に設定すると、BOTTOM = 20、TOP = 100 のように、クアッド コア CPU ではうまく動作しますが (CPU 使用率が高くなります)、シングル CPU ではうまく動作しません (CPU 使用率は比較的大きく変動します。 ）。
BOTTOM と TOP をより大きな数値 (BOTTOM = 100、TOP = 300) に設定すると、シングル CPU ではうまく機能しますが、クアッド コア CPU ではうまく機能しません。
どちらの環境でも、どちらの条件でも、メモリはあまり使用されていません (せいぜい 50M 程度)。

論理的には、BOTTOM と TOP を大きくすると、(メモリがあまり使用されていない場合) パフォーマンスが向上します。これは、ハンドラー スレッドが処理する項目が増えるためです。しかし、事実はそうではないようです。

問題の原因を見つけるために、いくつかの方法を試しました。lock(mQueue)そして、スレッドを維持するために使用すると、上記の2つのCPU条件で両方ともうまく機能することがわかりました。
新しいcountKeepingスレッドは主にこのようなものです

だから私の質問は

1. countKeeping threadlockで使用しなかった場合、グローバル キューの範囲がさまざまな CPU 条件でパフォーマンスに影響するのはなぜですか (ここでは、パフォーマンスは主に CPU 使用率です)。
2. countKeeping threadで使用するlockと、さまざまな条件でパフォーマンスが向上します。何がこれに実際に影響しますか?lock
3. を使用する代わりに「追加可能」ステータスを変更するより良い方法はあります ManualResetEventか?
4. 私の要件に合ったより良いモデルはありますか？または、プロデューサースレッドが継続的かつ迅速に動作 するときに、メモリがあまり使用されないようにするより良い方法はありますか?

---UPDATE---
Producer threadの主要部分は以下の通りです。STEPは、データベースからの各クエリのアイテム数です。クエリは、すべてのアイテムがクエリされるまで、順番に行われます。

ボタンをクリックすると、サイクルが開始され、データベースが読み取られ、クエリの各行が別のサーバーに送信されます。応答を取得すると、サイクルが継続します。

コードは次のように実装されます

と

問題は、リクエストが送信されたときに回答が得られない場合があることです。私の場合、これは正常です。しかし、そうでない場合は、答えが来て、サイクルが停止します。ループタイマー内で行う必要があります。応答がないためにサイクルが停止した場合、30 秒でサイクルが続行されます。

タイマーはしなければならないでしょう

最近、ManualResetEventSlim クラスを使用すると、ManualResetEvent クラスと比較してパフォーマンスが向上するという MSDN のリンクを見つけました。

「.NET Framework 4 では、待機時間が非常に短いと予想される場合に、パフォーマンスを向上させるために System.Threading.ManualResetEventSlim クラスを使用できます」.

https://msdn.microsoft.com/en-us/library/5hbefs30%28v=vs.110%29.aspx

私の理解が間違っている場合は修正してください。

WaitOne(1000) を 1 秒間呼び出した場合

• ウィンドウは、他のスレッドの実行をブロックすることとは別に、現在のスレッドを一定時間スリープさせ、通知されるとウェイクアップします。

• ここでブロッキングという言葉は、スレッドが通知されるまで一定時間スリープすることを意味しますか?

• この文は、「待ち時間が非常に短いと予想される場合」という意味ですか?

  WaitOneの内部プロセスを理解するためのウェブサイトを誰か提案してもらえますか

過去に他社が開発したアプリを改造しようとしている...

このアプリはオンライン取引を行います (C# 用に開発された API を使用します)。基本的に、ユーザーがチェックまたはチェック解除できるいくつかの構成パラメーターを設定し、開始および停止ボタンがあるアプリ構造を持っています。

スタートボタンをクリックすると..私はすべてのapingやその他のものを実行する関数を渡し、それをメインフォームクラスに割り当てることでスレッドを作成しています

停止ボタンをクリックすると、アプリは単にスレッドを中断しています

アプリが停止し、アプリの機能 (aping) を再開する唯一の方法は、スタート ボタンを押してスレッドを再起動することです。

新機能として、このスレッドが自動的に停止して再起動するようにしたい..特定のストップロスに達するたびに最初からやり直す...しかし、私はそれを行うことができませんでした

私が疲れているのは、次のようなManualResetEventです

aping_function メソッドで特定のイベントが一致する場合、mrse.reset() および mrse.set().. を実行しますが、効果がないようです (完全に再起動しない)。

どうすればこれを達成できますか

ThreadPool.UnsafeRegisterWaitForSingleObject一部のアプリが終了した場合に通知するために使用しようとしています。少なくとも私が望むものでは機能しますが、メインフォームを閉じた直後に例外がスローされます:

SEHException : 外部コンポーネントが例外をスローしました

スタックトレース：

コードは次のとおりです。

コールバックが呼び出されるのを待つ必要さえありません。コードを実行するだけで、その直後にメイン フォームを閉じると例外がスローされます。

興味深いことに、次のようにクラスOpenProcessを使用する代わりに、ネイティブ関数を使用してプロセス ハンドルを取得する場合:Process

その後、例外なく正常に動作しますが、この場合、可能な限り管理されたラッパーに固執する方が良いかどうかはわかりません。Processまた、クラスの使用時にこの例外がスローされる理由を理解したいと思います。フラグ (文書化されている必要なフラグ) が、 usingと wrapper のSynchronize違いを生んでいるようです。この場合、交換できないように見える場合、またはここで何かを見逃しましたか?OpenProcessProcessProcessOpenProcess

その他の情報: .NET 4.0 をターゲットとする Visual Studio 2010

ありがとうございました。