問題タブ [manualresetevent]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - Webservice: AsyncCall が終了しました: しかし、WaitOne() はまだ待機中です
- Command Line Exe を介して WebService メソッドを呼び出しています。
- このメソッド呼び出しは非同期呼び出しであり、呼び出しの後に WaitOne を使用しています。
- 完成したメソッドで ManualRest.Set() を実行しています。
上記のセットアップは、非同期メソッドが 10 ~ 20 分以内に返されるケースの 99% で正常に機能します。
Async Call に 2 ~ 3 時間かかり、WaitOne() の後のコードが実行されない場合に問題が発生します。
waitone() の前後と Completed イベントにもログを書き込んでいますが、3 時間の非同期呼び出しの後、コントロールが元に戻らないようです。
上記のヘルプ/ポインタ...
ありがとう。
c# - ManualResetEvent - WaitOne() は、ある時点でスレッドを解放していないようです
私はマルチスレッドフォームアプリケーションを持っています.これは問題の部分がどのように設計されているかです:
スレッド 2 (BatchPreviewAssistant クラス) は、プライマリ インターフェイス スレッドが画像の読み込みタスクを渡すのを待機しています。タスクが受信されると、BatchPreviewAssistant は N=5 の待機中の PrimaryLoader スレッドにタスクを割り当てて有効にします。PrimaryLoaders は、_startEvent と _endEvent の 2 つの手動リセット イベントを使用して開始/停止された無限ループとして実行されています。また、N 個の手動リセット イベント _parentSyncEvent の配列があり、PrimaryLoaders から BatchPreviewAssistant への処理の終了を通知します。
したがって、通常、各 PrimaryLoader は _startEvent.WaitOne() で待機しています。BatchPreviewAssistant がそれらをアクティブにする必要があり、RunPrimaryLoaders() を実行すると、最初に _endEvent と _parentSyncEvents がリセットされ、次に _startEvent が設定されます。現在、WaitHandle.WaitAll(_parentSyncEvents) でブロックされます。_startEvent.Set() により、すべての PrimaryLoader が続行されます。各 PrimaryLoader が完了すると、5 つすべてが設定されるまで、_parentSyncEvent に独自のイベントが設定されます。この時点で、すべての PrimaryLoader が _endEvent.WaitOne(これで、_parentSyncEvents がすべて設定され、BatchPreviewAssistant が続行できるようになります。BatchPreviewAssistant は _startEvent をリセットし、_endEvent を設定して PrimaryLoaders を解放し、ループの先頭に戻ります。
BatchPreviewAssistant:
プライマリローダー:
このコードは、このようなループを何百回も作成するのに非常にうまく機能しますが、特にストレステスト中に、時々問題が発生します。BatchPreviewAssistant が _endEvent.Set() を設定すると、_endEvent.WaitOne(); でどの PrimaryLoader も解放されません。BatchPreviewAssistant をチェックインすると、イベントが実際に設定されていることがわかりますが、PrimaryLoaders は解放されていません。
このような設計に問題を引き起こす可能性のある明らかな問題はありますか? 回避策としていくつかの方法を試すことができますが、このアプローチの何が問題なのかを確認できれば幸いです。
念のため、PrimaryLoaders を初期化して開始する方法についても情報を提供しています。
サンプルを簡略化するために、無関係なコードが削除されていることに注意してください。
追加: サンプルが忙しすぎて、理解するのが難しいことに同意します。つまり、これは一言で言えば次のとおりです。
wcf - WCF 非同期 - ManualResetEvent の使用方法
非同期wcfサービスで「ManualResetEvent」を使用する方法を教えてもらえますか? 非同期 wcf サービスを呼び出すコンソール アプリケーションがあり、「oncomplete」イベントの終了後にコンソール アプリケーションを閉じたいと考えていました。
可能であれば、サンプルを提供してください。
前もって感謝します。
c# - ManualResetEvent.WaitOne() で ObjectDisposedException をキャッチしても安全ですか?
これは、ManualResetEvent を通知してすぐに閉じても安全ですか? と密接に関連しています。その問題に対する 1 つの解決策を提供する可能性があります。
同じ作業を実行したい可能性のあるスレッドがたくさんあるとしますが、それを実行できるのは 1 つだけで、他のスレッドはワーカーが完了するまで待機してその結果を使用する必要があります。
だから、基本的には一度だけ仕事をしたいのですか?
更新: これは、.net 4 の Lazy<T> を使用して対処できる初期化の問題ではないことを付け加えておきます。1 回とは、 task ごとに 1回という意味で、これらのタスクは実行時に決定されます。これは、以下の単純化された例からは明らかではないかもしれません。
前述の質問に対する Hans Passant の回答の簡単な例を少し変更すると、次のようにすれば安全だと思います。(今説明したユースケースとは少し異なりますが、スレッドとその関係に関しては同等です)
私の質問の核心は次のとおりだと思います。
ObjectDisposedException が原因で中止された WaitOne の呼び出しは、メモリ バリアに関して、WaitOne の呼び出しが成功したことと同等ですか?
これにより、他のスレッドによる変数workResultへの安全なアクセスが保証されます。
私の推測: それは安全でなければなりません。そうでなければ、そもそも ManualResetEvent オブジェクトが閉じられたことを WaitOne が安全に判断するにはどうすればよいでしょうか?
c# - このバックグラウンド スレッド キューはパフォーマンスの高い実装ですか?
具体的には、私は疑問に思っています:
ManualResetEvent は、待機状態のときにリソースを消費しますか? コンテキスト切り替えのパフォーマンス低下は、待機状態のスレッドに適用されますか?
それぞれの作業が少ない複数の BackgroundThreadQueues を使用するか、より多くの作業を行う 1 つの BackgroundThreadQueues を使用するかを選択でき、複数を使用することを選択した場合...待機中のスレッド キューは、何もしていないときにプロセスのパフォーマンスに影響しますか?
C# または別のロック戦略で使用する必要がある、より良い FIFO スレッド キューはありますか?
任意の提案をいただければ幸いです。
c# - ManualResetEventは、待機状態のときにCPUを消費しますか?
具体的には、コンテキストスイッチングのパフォーマンス低下は、待機状態のスレッドに適用されますか?
ManualResetEventまたはWaitHandleは、どのような条件または状況でリソースを消費する可能性がありますか?
multithreading - ManualResetEvent.WaitOne はすべてのスレッドをブロックします
私は次のコードを持っています
DownloadAsync の場所
したがって、私の問題は、 downloadHandle. Set() が呼び出されないことです。しかし、私はなぜ理解していないのですか?私は DownloadAsync の新しいスレッドを作成し、downloadHandle.WaitOne() は彼をブロックすべきではありません。
私が必要とするのは、Async の代わりに Sync メソッドを作成することです。
ありがとう!
UPD: 非同期呼び出しでソース コードを更新しました。
c# - ManualResetEventサイズチェックは、複数のスレッドを待機するのに十分ですか?
私は現在、単一のスレッドに対してManualResetEventを使用して、複数のスレッドがスレッドマネージャーのキューに何かを追加するのを待機しています。スレッドマネージャーが手動リセットイベントを使用してシグナルを受信すると、追加されたアイテムをデキューし、さらに処理を行います。私の唯一の問題は、複数のセットがトリガーされた場合、他のキューアイテムが処理されないことです。(ポイントBを参照)
ここでの私の回避策は、ポイントAにキューサイズ条件を追加することです。デッドロックを回避するためにこれを実行する別の方法はありますか?
注:ManualResetEventの使用例で示されている通常のシナリオでは、単一のスレッドでイベントを待機している複数のスレッド(ManualResetEvent.Wait)がありますが、ここでは複数のスレッドがイベントをトリガーします(ManualResetEvent.Set)。このシナリオで使用される他のクラスはありますか?
c# - EventWaitHandle.Set() が現在のスレッドをブロックする原因は何ですか?
ManualResetEvent のインスタンスで Set メソッドを呼び出していますが、デッドロックが発生することがあります。ドキュメントには、これがブロッキング メソッドであることを示すものは見つかりません。MRE.Set がブロックされる原因は何ですか?
スタックトレース:
c# - FileStreamから2回読み取る
GetServiceMap()メソッドがあり、デシリアライザーを呼び出してストリームを開き、そこから何かを読み取ります。
問題は、同じストリームでデシリアライザーを呼び出すGetAllGroups()メソッドがあることです。
どうすれば同期できますか?ManualResetEventで多分?
デシリアライズメソッド: