問題タブ [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# - ManualResetEvent はいつ破棄する必要がありますか?
ManualResetEvent を使用してスレッドを同期するアプリケーションを使用しています。FxCop から、それらのオブジェクトを破棄するように言われました。私は同じことを言った次の議論を見つけました:
EventWaitHandle を Dispose() または Close() する必要がありますか?
しかし、ManualResetEvent のインスタンスを破棄するタイミングがわかりません。
次の簡略化されたコードは、問題を示しています。
問題は、ManualResetEvent の複数のインスタンスが存在し、複数のスレッドが各インスタンスを待機していることです。
リスト内のインスタンスを暗記すると、いつ破棄するかわかりません。WaitOne() 呼び出しの後に破棄すると、複数回破棄され、他のスレッドがまだ待機している間に破棄される可能性があります。
イベントを作成したスレッドには、イベントへの参照がありません。この MRE を待っている他のスレッドがあるため、setter-thread はそれを破棄しないでください。前述のように、待機中の各スレッドはそれを破棄できません。
問題は、この ManualResetEvent をいつ破棄する必要があるかということです。
c# - ManualResetEvent の待機が設定後に解放されない
Web から 2 つの JSON ファイルをダウンロードしています。その後、2 つのページの読み込みを許可したいのですが、その前には許可したくありません。ただし、ManualResetEvent
ページをロードするために設定する必要がある は「起動」しません。セットされることはわかっていますが、WaitOne
決して戻りません。
ダウンロードを開始する方法:
を設定するダウンロード方法ManualResetEvent
待機メソッド (この場合はコンストラクター)
そのコンストラクターにアクセスしようとする前に待機すると、if ステートメントを簡単に通過し、WaitOne
.
何か案は?
c# - 待機ハンドルの使用
私はこのようなことをしようとしています:
コードの他の場所には、以下を呼び出すメソッドがあります。
したがって、LongRunningOperation() が実行されます。
問題は、スレッドの実行handler.Set()
中に が再度呼び出される可能性があることです。AsyncWait()
LongRunningOperation()
これにより、がまだ実行されている間に が呼び出さLongRunningOperation()
れるたびに、 が呼び出されることはありません。handler.Set()
AsyncWait()
LongRunningOperation()
これを正しくする方法は?:(
c# - BackgroundWorker を使用した ManualResetEvent : WaitOne() の間、現在のスレッドはビジーですか?
次の状況を想像してください。
サードパーティのサーバーから ui スレッドでシグナルを受け取りました。
RunAsync を使用して BackgroundWorker を開始し、データベースと別の非同期スレッドからデータを取得します。これは、UI スレッドではなく、別のハードウェアをポーリングして信号を受信します。
bg の DoWork イベントハンドラ内で manualresetEvent.Reset() を呼び出します。次に、データ取得メソッドを呼び出し、次に manualresetEvent.Set() を呼び出し、最後に UI スレッドでメソッド METH_UI_1 を呼び出して呼び出します。
他のハードウェア スレッドはハードウェア データを受信し、それ自体が Invoke を介して ui スレッドに渡され、取得したハードウェア データに応じて定期的にいくつかの ui 要素を設定します。
データベースからのデータもまだフェッチできませんが、UI は 2 番目の非同期スレッドによってポーリングされるハードウェア データに反応する必要があります。
METH_UI_1 で manualresetEvent.WaitOne(); を呼び出します。
バックグラウンドワーカーがビジーで、複数のタスクを同時に実行できないという例外が発生することがあります。
a) ManualResetEvent オブジェクトは本当に必要ですか?
b) バックグラウンド ワーカーがビジー状態でなくなったときに、WaitOne() のみを発行するために isBusy プロパティをチェックするだけで十分でしょうか?
更新: コード。
MainForm.cs (サード パーティのハードウェア ベンダー、コンポーネント、UI スレッドで処理されるイベント ハンドラー)
runworkersynch はこれを行います:
BackGroundWorker の WorkCompleted EventHandler:
c# - EventHandle.WaitOne + WebBrowser = DocumentComplete 待機時のデッドロック
C# プログラムでの WebBrowsing の自動化に問題があります。以前に BHO にコードを使用したことがあり、そこでは機能していました。しかし、純粋な c# プログラム内では、ある種のデッドロックがあるようです。検索ボタンをクリックしてから、documentcomplete が通知されるまで (manualresetevent を介して) 待機するようにプログラムに指示しました。しかし、ManualResetEvent がタイムアウトを通知するまで、検索ボタンのクリックは処理されないようです。その後、クリックが行われ、DocumentComplete-Event も発生します。
そのプログラムの構造について: WebBrowser-Control は WindowsForm の一部です。WebBrowser コントロールは、スレッドを実行するクラスに渡されます。このクラスは、ロードされた Web ブラウザーに応じた具体的な動作がプログラムされている別のクラスに制御を再び渡しました。
したがって、コードでは次のようになります。
スレッドのセットアップ
/li>withingtheRunner-Methodの処理
/li>PlaceTipp メソッド
/li>デッドロックが発生している SearchTipp-Method:
/li>
ここで何が起こっているのか、誰かアイデアがありますか?
ありがとう
ライトブリンガー
c# - ManualResetEvent と while ループ
ManualResetEvent は基本的に、他のスレッドに対して「続行するシグナルを受信した場合にのみ続行できます」と伝え、特定の条件が満たされるまで特定のスレッドの実行を一時停止するために使用されます。私が聞きたいのは、while ループを使用して簡単に目的を達成できるのに、なぜ ManualResetEvent が発生するのかということです。次のコンテキストを考慮してください。
にいくらか似ている
ManualResetEvent が while ループよりも適している特定のコンテキストはありますか?
c# - ManualResetEvent WaitOne は、CollectionView の所有者スレッドをブロックします
いくつかのBackgroundWorker
. ObservableCollection
処理中に、UI にバインドされている を更新する必要がある場合があります。
この場合、とThreadableObservableCollection
のスレッドセーフなメソッドを提供する を作成しました。私は.NET 4.5を使用していますが、他の多くの無効なアクセス例外なしでは機能しませんでした。私のように見えます:Insert
Remove
RemoveAt
BindingOperations.EnableCollectionSynchronization
Collection
アプリケーションでウィザードを使用している間、これは期待どおりに機能しています。現在、NUnit を使用してアプリケーションの統合テストを作成しています。
WizardViewModel が作業を終了するのを待ち、Steps-Collection に挿入されたいくつかのページを探すリスナーがあります。非同期作業が完了したら、Validate を使用してビューモデルの状態を確認できます。
残念ながらManualResetEvent
、ウィザードが閉じるのを待つために a を使用しています。これは次のようになります。
ここで問題があります。アプリケーションが実行されている間、UI スレッドはブロックされませんが、コレクションは問題なく更新できます。しかし、私のテストケースでは、ViewModel (およびそのためコレクション) を初期化する「メイン」スレッドは、テストコードによってブロックされている AppDomainThread です。コレクションを更新したいのですが、 AppDomainThreadsafeInsert
スレッドを使用できません。
しかし、ウィザードが終了するまで待たなければなりません。どうすればこの種のデッドロックを解決できますか? または、これに対するよりエレガントなソリューションはありますか?
編集:
ユーザーインターフェイスがあるかどうかを確認してこの問題を回避し、それからアプリケーションスレッドで呼び出します。それ以外の場合は、別のスレッドで意図的にコレクションを変更します。これは例外を防ぎませんが、テストからは認識されません...それにもかかわらず、アイテムは挿入されますが、NotifyCollectionChanged
-Handler だけが呼び出されません (とにかく UI でのみ使用されます)。
これは醜い回避策であり、私はまだクリーンなソリューションに興味があります.
別の Dispatcher を使用して (たとえば) ViewModel 全体を作成し、これを使用してコレクションを変更する方法はありますか?
windows - setEvent は ResetEvent なしで呼び出されます
手動リセット イベントが setEvent を使用して設定されているが、ResetEvent を使用してリセットされていない場合はどうなりますか。そのイベントは複数回トリガーされます。つまり、イベントが処理されている間、再びイベントが設定されます。
サンプル タスクは次のとおりです。
ここで、hEvent1 のケースが実行中 (つまり、まだ設定されている) に、何らかの形で再び hEvent1 がトリガーされたとします。手動リセット イベントですが、意図的に ResetEvent(hEvent1) を配置していません。では、競合状態はありますか?