manualresetevent

When should a ManualResetEvent be disposed?

百般思念 提交于 2019-12-10 14:17:11
问题 I'm using an application that synchronizes threads using ManualResetEvent. FxCop told me to dispose those objects. I found the following discussion which told me the same: Do I need to Dispose() or Close() an EventWaitHandle? But I don't know when to dispose an instance of a ManualResetEvent. The following simplified code demonstrates the problem: private void btn_Click(object sender, EventArgs e) { var mre = new ManualResetEvent(false); new Thread(() => this.SetEvent(mre)).Start(); for (int

ManualResetEvent WaitOne not unblocking

时光怂恿深爱的人放手 提交于 2019-12-07 08:25:14
问题 I'm a little confused over a ManualResetEvent that I'm using which doesn't appear to be unblocking. Anyone know why this might be the case? The scenario I've got is something along these lines. The real situation is quite complicated and I've not managed to isolate a section of code that's reasonable to post to reproduce the issue. EDIT I've updated the code example below. This is execute in a number of different dialogs and I have noticed that one of them hits the this.mre.WaitOne(); Then

Will the ManualResetEvent consume cpu while it is in a wait state?

匆匆过客 提交于 2019-12-07 07:28:48
问题 More specifically, does the performance degradation of context switching apply to threads that are in a wait state? Under what conditions or circumstances would a ManualResetEvent, or WaitHandle, be likely to consume resources? 回答1: A ManualResetEvent doesn't have a wait state. The only thing that can wait on an MRE is a thread . And yes, a thread consumes plenty of precious resources needlessly when it is not doing what it was made to do, execute code. A megabyte of virtual memory and a

ManualResetEvent WaitOne not unblocking

若如初见. 提交于 2019-12-05 12:33:11
I'm a little confused over a ManualResetEvent that I'm using which doesn't appear to be unblocking. Anyone know why this might be the case? The scenario I've got is something along these lines. The real situation is quite complicated and I've not managed to isolate a section of code that's reasonable to post to reproduce the issue. EDIT I've updated the code example below. This is execute in a number of different dialogs and I have noticed that one of them hits the this.mre.WaitOne(); Then what happens is I get a "Server Busy" dialog, where I need to press 'switch to' or 'retry', which will

Is it safe to signal and immediately close a ManualResetEvent?

a 夏天 提交于 2019-12-01 15:23:48
I feel like I should know the answer to this, but I'm going to ask anyway just in case I'm making a potentially catastrophic mistake. The following code executes as expected with no errors/exceptions: static void Main(string[] args) { ManualResetEvent flag = new ManualResetEvent(false); ThreadPool.QueueUserWorkItem(s => { flag.WaitOne(); Console.WriteLine("Work Item 1 Executed"); }); ThreadPool.QueueUserWorkItem(s => { flag.WaitOne(); Console.WriteLine("Work Item 2 Executed"); }); Thread.Sleep(1000); flag.Set(); flag.Close(); Console.WriteLine("Finished"); } Of course, as is usually the case

To make a choice between ManualResetEvent or Thread.Sleep()

烈酒焚心 提交于 2019-11-29 02:16:05
I am not sure which strategy to adopt...I am focusing on my operation getting completed, but I'd also like to keep performance issues to a min too...there is a method called Execute() which has to wait (run synchronously) until an operation completes. This operation happens on another thread. There are 2 ways to implement the same thing... By using ManualResetEvent void Execute() { taskHandle = new ManualResetEvent(false); . . //delegate task to another thread . . taskHandle.WaitOne(); } OR By using a simple while construct void Execute() { . . //delegate task to another thread . . while (

WinForms RichTextBox : how to reformat asynchronously, without firing TextChanged event

你离开我真会死。 提交于 2019-11-28 04:04:26
问题 This is a followup to WinForms RichTextBox: how to perform a formatting on TextChanged? I have a Winforms app with a RichTextBox, the app auto-highlights the content of said box. Because the formatting can take a long time for a large document, 10 seconds or more, I've set up a BackgroundWorker to do the re-formatting of a RichTextBox. It walks through the text and performs a series of these: rtb.Select(start, length); rtb.SelectionColor = color; While it is doing this, the UI remains

ManualResetEvent vs. Thread.Sleep

会有一股神秘感。 提交于 2019-11-27 21:28:28
I implemented the following background processing thread, where Jobs is a Queue<T> : static void WorkThread() { while (working) { var job; lock (Jobs) { if (Jobs.Count > 0) job = Jobs.Dequeue(); } if (job == null) { Thread.Sleep(1); } else { // [snip]: Process job. } } } This produced a noticable delay between when the jobs were being entered and when they were actually starting to be run (batches of jobs are entered at once, and each job is only [relatively] small.) The delay wasn't a huge deal, but I got to thinking about the problem, and made the following change: static ManualResetEvent

How to keep a .NET console app running?

生来就可爱ヽ(ⅴ<●) 提交于 2019-11-27 02:48:22
Consider a Console application that starts up some services in a separate thread. All it needs to do is wait for the user to press Ctrl+C to shut it down. Which of the following is the better way to do this? static ManualResetEvent _quitEvent = new ManualResetEvent(false); static void Main() { Console.CancelKeyPress += (sender, eArgs) => { _quitEvent.Set(); eArgs.Cancel = true; }; // kick off asynchronous stuff _quitEvent.WaitOne(); // cleanup/shutdown and quit } Or this, using Thread.Sleep(1): static bool _quitFlag = false; static void Main() { Console.CancelKeyPress += delegate { _quitFlag =

How to keep a .NET console app running?

橙三吉。 提交于 2019-11-26 10:09:49
问题 Consider a Console application that starts up some services in a separate thread. All it needs to do is wait for the user to press Ctrl+C to shut it down. Which of the following is the better way to do this? static ManualResetEvent _quitEvent = new ManualResetEvent(false); static void Main() { Console.CancelKeyPress += (sender, eArgs) => { _quitEvent.Set(); eArgs.Cancel = true; }; // kick off asynchronous stuff _quitEvent.WaitOne(); // cleanup/shutdown and quit } Or this, using Thread.Sleep(1