問題タブ [manualresetevent]

これに関するドキュメントを読みましたが、理解していると思います。AutoResetEventコードが を通過すると はリセットされますが、 はリセットされませevent.WaitOne()んManualResetEvent。

これは正しいです？

ManualResetEvent の使用から Thread.Join などの Thread メソッドの使用に切り替えるデザイン パターンを探しています。現在、非同期呼び出しを行ってから、ManualResetEvent を使用して非同期呼び出しが終了するまで待機してから、呼び出しを行ったスレッドを続行しています。

より安定した読みやすいコードを生成する実装があればうれしいです。C# の yield キーワードと、もしあれば F# Async を使用した実装を見てみたいと思います。

ありがとう。

msdnのこの記事をプライマリ ヘルパーとして使用してコードを記述しました

私のコード:

これが起こることです、私はBeginAcceptにブレークポイントを設定しました（問題があると思いました）が、正常にステップします.しかし、「_AllDone.WaitOne（）」をステップしようとすると-サーバーがクラッシュします。

win32 フォーム アプリケーションで _allDone を使用できない場合 - プロジェクトを作成するにはどうすればよいですか?

編集

Accept() に _AllDone.Reset() を書いたことを忘れていましたが、そこには行きません。そこにブレークポイントを設定しましたが、行きません。

次のバックグラウンド処理スレッドを実装しました。ここJobsで、はQueue<T>：

これにより、ジョブが入力されてから実際に実行が開始されるまでの間に顕著な遅延が発生しました（ジョブのバッチは一度に入力され、各ジョブは[比較的]小さいだけです）。遅延はそれほど大きくありませんでした。しかし、私は問題について考えるようになり、次の変更を加えました。

ジョブを追加するスレッドがロックされ、ジョブの追加が完了する_workerWaitと呼び出さ_workerWait.Set()れるようになりました。このソリューションは（一見）即座にジョブの処理を開始し、遅延は完全になくなります。

私の質問は、一部は「なぜこれが起こるのか」でThread.Sleep(int)あり、指定したよりも長く非常によく眠ることができると認められており、一部は「このレベルのパフォーマンスをどのようにManualResetEvent達成するのですか？」です。

編集：誰かがアイテムをキューに入れる機能について尋ねたので、これは現在の完全なシステムと一緒にあります。

ブロックを解除していないように見える使用している ManualResetEvent について少し混乱しています。なぜこれが当てはまるのか誰にも分かりますか？

私が持っているシナリオは、これらの線に沿ったものです。実際の状況は非常に複雑で、問題を再現するために投稿するのが妥当なコードのセクションを分離することができませんでした。

EDIT
以下のコード例を更新しました。これはさまざまなダイアログで実行され、そのうちの 1 つが this.mre.WaitOne(); にヒットすることに気付きました。次に、「サーバービジー」ダイアログが表示され、「切り替え」または「再試行」を押す必要があります。これにより、コードが WaitOne() 呼び出しを通過し、すべてが機能します。それがどのように関連しているかはわかりませんが、明らかに重要なものです。

これは、
WinForms RichTextBoxのフォローアップです。TextChangedでフォーマットを実行する方法は？

RichTextBoxを備えたWinformsアプリがあります。このアプリは、そのボックスのコンテンツを自動ハイライトします。大きなドキュメントではフォーマットに10秒以上かかることがあるため、RichTextBoxの再フォーマットを行うBackgroundWorkerを設定しました。テキストをウォークスルーし、次の一連の処理を実行します。

これを実行している間、UIは応答性を維持します。

BackgroundWorkerは、TextChangedイベントからキックオフされます。このような：

バックグラウンドワーカーメソッドは次のようになります。

ただし、SelectionColorに割り当てるたびに、TextChangedイベントが発生します。無限ループです。

外部で発生したテキストの変更と、フォーマットを実行しているBackgroundWorkerで発生したテキストの変更を区別するにはどうすればよいですか？

テキスト形式の変更とは関係なく、テキストコンテンツの変更を検出できれば、これを解決することもできます。

これに対する答えを知っておくべきだと思いますが、壊滅的な間違いを犯している可能性がある場合に備えて、とにかく尋ねます.

次のコードは、エラー/例外なしで期待どおりに実行されます。

もちろん、マルチスレッド コードではよくあることですが、テストが成功しても、これが実際にスレッド セーフであるとは証明されません。ドキュメントには、 a の後に何かをしようとすると未定義の動作が発生すると明確に記載されていますが、Close前に を置いた場合もテストは成功します。SetClose

私の質問は、メソッドを呼び出すときに、呼び出し元に制御を返す前に、待機中のすべてのManualResetEvent.Setスレッドに通知することが保証されているかということです。言い換えると、 への呼び出しがこれ以上ないことを保証できると仮定すると、ここでハンドルを閉じても安全ですか? または、状況によっては、このコードによって一部のウェイターがシグナルを受け取るのを妨げたり、？_WaitOneObjectDisposedException

ドキュメントSetには、「シグナル状態」になると書かれているだけです。ウェイターが実際にいつそのシグナルを受け取るかについては何も主張していないようです。

現在、外部クライアントからの接続を通常どおりリッスンし、接続時にリクエストを処理するサーバータイプのアプリケーションを作成しています。

現時点では、私の実装では、クライアントが接続するたびにスレッドのペアが作成されます。1 つのスレッドはソケットから要求を読み取ってキューに追加し、2 つ目のスレッドはキューから要求を読み取って処理します。

基本的に、これらのスレッドをすべて持つのはやり過ぎだと思うかどうか、そして重要なことに、このアプローチが問題を引き起こすかどうかについての意見を探しています.

ほとんどの場合、これらのスレッドはアイドル状態になることに注意することが重要です。私は両方のスレッドで待機ハンドル (ManualResetEvent) を使用しています。リーダー スレッドは、メッセージが利用可能になるまで待機し、利用可能な場合はそれを読み取り、プロセス スレッドのキューにダンプします。Process スレッドは、メッセージがキューにあることをリーダーが通知するまで待機します (ここでも、待機ハンドルを使用します)。特定のクライアントが実際にサーバーを攻撃していない限り、これらのスレッドは待機状態になります。これは費用がかかりますか？

私は少しのテストを終えました.1,000台のクライアントが絶えずしつこく接続されていました-サーバー(つまり、2,000以上のスレッド)で、非常にうまく対処しているように見えました.

別のスレッドでいくつかのサービスを起動するコンソールアプリケーションについて考えてみます。ユーザーがCtrl+Cを押してシャットダウンするのを待つだけです。

これを行うためのより良い方法は次のうちどれですか？

または、Thread.Sleep（1）を使用して：