I have a button on my application whose click event:
private void btn_Click(object sender, EventArgs e)
{
btn_DoMyAction();
}
and btn_DoMyAction is
private void btn_DoMyAction()
{
//lock (_lock) //--> Is this necessary
{
...
... //long code block(I mean non automic)
...
}
}
I am calling btn_DoMyAction from both click event and from windows timer tick
private void myTimer_Tick(object sender, EventArgs e)
{
btn_DoMyAction();
}
I have two questions:
1-) Is lock necessary in btnProcessNextBandBarcode_DoMyAction (I am asking first question, because as far as I debug, it seems it queues call, and lock seems to be unnecessary)
2-) I want to skip thread instead of queue on tick or button click
Additional question is:
if the answer no for first question, if btn_DoMyAction is called from Thread(None timer), how should I take action for automicity
It depends on which timer are you using. If you grab timer from toolbox, you're using System.Windows.Forms.Timer. According to the documentation,
This Windows timer is designed for a single-threaded environment where UI threads are used to perform processing.
So you don't have to use lock because btn_Click and myTimer_Tick are executed in the same thread.
Additional question:
If you call btn_DoMyAction from another thread, in gerenal you should use lock because it might be called from UI thread and another thread.
EDIT:
2. Because Timer is executed in UI thread and action executed on click on button is also executed in UI, situation that tick arrive and but previous execucion does not comlpleate cannot occure (because everything is executed in one thread). If you would like timer that start execution after particular time passes from complition of this action, you should use diferent timer - System.Threading.Timer should be ok - you can start timer at the end of execution (when execution caused by timer).
Related
I would like to gracefully stop an endlessly looping thread from running whenever a button is clicked. Here's what as I understand should work:
bool running = true;
private Thread myThread = new Thread(new ThreadStart(threadWorker));
private void threadWorker()
{
while(running)
{
...
}
}
private void button_click(object sender, EventArgs e)
{
running = false
myThread.Join();
...
}
However clicking the button freezes the UI thread. Pausing the program to debug shows it stuck on Thread.Join(). If I put the "running" flag on a separate button and click it before joining then it works fine, but this way it's is as if the flag is never changed ant the method never ends.
What am I doing wrong?
EDIT: This question is NOT a duplicate of "Why is CPU usage constantly increasing after starting/stopping threads?", adding "volatile" to the flag declaration did not solve the problem.
In my case the program was freezing at the UI update invokes (thanks to usr for telling me I can check what the other threads are doing). Replacing Control.Invoke with Control.BeginInvoke solved the problem.
The worker thread seems to be stuck at an invoke to update a chart.
The worker tries to access the UI thread through an invoke. But the UI is stuck waiting in the Join. It's a deadlock.
Thread in conjunction with UI is obsolete. Switch to using await and such problems go away.
Since you didn't mention otherwise, I suppose running is not declared volatile which means threadWorker() method doesn't check it's "real" value, but a cached value of it. Try declaring it as
volatile bool running;
I have a windows form (C#.NET) with a statusLabel that I can not seem to get to update in the middle of a process in event handler methods. My code looks like this...
void Process_Completed(object sender, EventArgs e)
{
string t = "Process is finished!";
this.Invoke(new StatusLabelUpdator(updateStatusLabel), new object[] { t });
}
void Process_Started(object sender, EventArgs e)
{
string t = "Process has begun";
this.Invoke(new StatusLabelUpdator(updateStatusLabel), new object[] { t });
}
private delegate void StatusLabelUpdator(string text);
private void updateStatusLabel(string text)
{
StatusLabel1.Text = text;
statusStrip1.Invalidate();
statusStrip1.Refresh();
statusStrip1.Update();
}
When I run the code, once the process starts, the Process_Started method is triggered, and a couple seconds later the Process_Completed method is triggered. For some reason I can not get the status label to ever display "Process has begun". It only ever displays "Process is finished!". As you can see I have tried invalidating, refreshing and updating the status strip which contains the status label but no success. I can't call update/refresh/invalidate on the statuslabel itself because those methods are not available to it. What am I doing wrong?
ADDED INFO:
The "process" is started by a button click on the form which calls a method in a separate class that looks like this:
public void DoSomeProcess()
{
TriggerProcessStarted();
System.Threading.Thread.Sleep(2000); // For testing..
TriggerProcessComplete();
}
and inside the TriggerProcessxxxx methods I trigger the events using this code...
var EventListeners = EH.GetInvocationList(); //EH is the appropriate EventHandler
if (EventListeners != null)
{
for (int index = 0; index < EventListeners.Count(); index++)
{
var methodToInvoke = (EventHandler)EventListeners[index];
methodToInvoke.BeginInvoke(this, EventArgs.Empty, EndAsyncEvent, new object[] { });
}
}
Finally, I have added Application.DoEvents() to the updateStatusLabel method but it did not help. I am still getting the same result. Here is my update method.
private void updateStatusLabel(string text)
{
StatusLabel1.Text = text;
statusStrip1.Refresh();
Application.DoEvents();
}
So I guess the "processing" is taking place on the UI thread but eventhandler is invoked on it's own thread which then invokes the control update back on the UI thread. Is this a dumb way of doing things? Note: The class that contains the DoSomeProcess() method is in a separate .NET ClassLibrary that i am referencing.
If you're doing your processing on the UI thread, it won't be able to do anything else (like redraw updated labels) while the processing is running. So for instance, if the processing is happening because the user clicked a button and is triggered by the button click handler (without explicitly placing it on another thread), it's running on the UI thread. Even though you update the label's text, it doesn't get drawn until it receives a paint message, at which point it's probably busy doing your processing.
The answer is to do long-running processing on a separate thread. The hack (IMHO) is to use Application.DoEvents to let the UI thread do some UI stuff during your processing. If you put one of those after updating the label and before you start your processing, odds are pretty high the label will get repainted. But then, during the processing, no further paint events can get processed (leading to half-drawn windows when someone moves another app window over your app and back, etc.). Hence my calling it a hack (even though, er, um, I've been known to do it :-) ).
Edit Update based on your edits:
Re
So I guess the "processing" is taking place on the UI thread but eventhandler is invoked on it's own thread...
I'm assuming DoSomeProcess is triggered from the UI thread (e.g., in direct response to a button click or similar). If so, then yes, your processing is definitely on the UI thread. Because TriggerProcessStarted triggers your callback asynchronously via BeginInvoke, you have no idea when it will run, but in any case your code then immediately launches into processing, never yielding, so no one else is going to be able to grab that thread. Since that's the UI thread, the call to the delegate will block on the Invoke call setting the label's text, whereupon it has to wait for the UI thread (which is busy processing). (And that's assuming it's scheduled on a different thread; I couldn't 100% convince myself either way, because Microsoft has two different BeginInvokes -- which IIRC one of the designers has acknowledged was a Really Dumb Idea -- and it's been a while since I fought with this stuff.)
If you make the TriggerProcessStarted calls to your callbacks synchronous, you should be okay. But ideally, schedule the processing (if it's not doing UI) on its own thread instead.
I have a WPF application with two background worker threads that operate while loading.
The first one (bw1) is spawned at application start, and the second one (bw2) is spawned after some time has elapsed.
I am in a situation that I CAN'T spawn the second background worker (bw2) from the first one's (bw1) "worker_completed".
Currently, I have a class-level bool variable (default false), and set it true in bw1's worker_completed.
And at the starting of bw2, I have a check to see if the above bool is false, and if so, bw2 will sleep for 100 milliseconds.
This works, for the most part. I'd like to improve it.
Can I use thread priority in bw1 (set it as highest, say) to ensure that bw1 is executed while bw2 sleeps?
Is there an event-driven way I can accomplish this goal?
Busy spinning (even with sleep) is a bad idea when you don't actually know when the event will occur, since you are checking blindly and using system resources unnecessarily.
Use an AutoResetEvent instead. At the beginning of bw2's code call ev.WaitOne() and in bw1's work_completed call ev.Set() to release bw2:
AutoResetEvent ev = new AutoResetEvent();
// bw1's work completed
private void bw1_workCompleted(object sender, RunWorkerCompletedEventArgs e)
{
ev.Set(); // release bw2 from waiting
}
// bw2's do work
private void bw2_DoWork(object sender, DoWorkEventArgs e)
{
ev.WaitOne(); // wait for the signal from bw1
// code
}
I've found this topic, How to suspend a thread by its name from the main thread?, but no satisfactory answer for what I'm trying to achieve.
I'm using threading and the WatiN class to perform events on two browsers in the same windows form at the same time.
I would like to, from the main UI thread, press a pause button available within one of the browsers that, through deriving the control name of the browser the pause button was pressed on, use that' name to figure out which sub-thread is associated with it's running logic, and pause that running logic until the play button is pressed.
Now today, we are so accomplished in terms of code and technology, there should be a way to do this.
What do you think?
Researching Ideas:
Pragmatically create ManualResetEvent and name it, use the UI pause button to grab the open browser control name, which is similiarly named after the child thread and browser control name (such a browser_5 & thread_5) to somehow target in on the MRE in the child thread, and close the gate to pause the logic. (But can this be done on child thread from the main UI thread?)
Don't use thread.Suspend
At first blush, it seems you could use thread.Suspend() to pause it and thread.Resume() to unpause it. But this is not a very good idea. See the MSDN article for thread.Suspend for why you should never use it unless you intend to terminate the AppDomain for that thread.
Do not use the Suspend and Resume methods to synchronize the activities of threads. You have no way of knowing what code a thread is executing when you suspend it. If you suspend a thread while it holds locks during a security permission evaluation, other threads in the AppDomain might be blocked. If you suspend a thread while it is executing a class constructor, other threads in the AppDomain that attempt to use that class are blocked. Deadlocks can occur very easily.
A sub-loop would work, but isn't perfect
It isn't the best option, but you could use a similar technique to the one described in that question you linked.
Instead of exiting the loop when a stop button is pressed, have it enter and wait inside a sub-loop while paused. Do a Thread.Sleep in that sub-loop to keep the CPU from pegging.
This isn't the most efficient code possible, because it keeps the thread running, and hangs for another 100ms when resuming.
public class YourForm : Form
{
private volatile bool _pause = false;
private void StartButton_Click(object sender, EventArgs e)
{
var thread = new Thread(
() =>
{
while (...)
{
// Periodically poll the _pause flag.
while (_pause)
{
// Now that we're paused, wait until we're unpaused
// before proceeding further in the outer loop
Thread.Sleep(100);
}
// Todo: The rest of the processing here
}
});
thread.Start();
}
private void PauseButton_Click(object sender, EventArgs e)
{
_pause = !_pause; // Toggle
}
}
Use thread synchronization
The best option is to use one of the various thread synchronization structures, like ManualResetEvent. Pausing threads is exactly what they're designed for. They're very efficient because they are implemented with a mutex.
public class YourForm : Form
{
private volatile bool _pause = false;
private static ManualResetEvent mre = new ManualResetEvent(true);
private void StartButton_Click(object sender, EventArgs e)
{
var thread = new Thread(ThreadImplementation);
thread.Start();
}
private void PauseButton_Click(object sender, EventArgs e)
{
_pause = !_pause;
if(_pause)
{
mre.Reset();
}
else
{
mre.Set();
}
}
private void ThreadImplementation()
{
while (...)
{
// Periodically wait on the event
mre.WaitOne();
// Todo: The rest of the processing here
}
}
}
Your ManualResetEvent idea is exactly correct.
Make the child threads WaitOne() on the event between each step.
To pause the request, call Reset(); to unpause, call Set().
If the event is set, WaitOne() will return immediately.
This will be much more efficient than repeated sleeps.
I suspect that a ManualResetEventSlim would be slightly faster.
I have a windows form (C#.NET) with a statusLabel that I can not seem to get to update in the middle of a process in event handler methods. My code looks like this...
void Process_Completed(object sender, EventArgs e)
{
string t = "Process is finished!";
this.Invoke(new StatusLabelUpdator(updateStatusLabel), new object[] { t });
}
void Process_Started(object sender, EventArgs e)
{
string t = "Process has begun";
this.Invoke(new StatusLabelUpdator(updateStatusLabel), new object[] { t });
}
private delegate void StatusLabelUpdator(string text);
private void updateStatusLabel(string text)
{
StatusLabel1.Text = text;
statusStrip1.Invalidate();
statusStrip1.Refresh();
statusStrip1.Update();
}
When I run the code, once the process starts, the Process_Started method is triggered, and a couple seconds later the Process_Completed method is triggered. For some reason I can not get the status label to ever display "Process has begun". It only ever displays "Process is finished!". As you can see I have tried invalidating, refreshing and updating the status strip which contains the status label but no success. I can't call update/refresh/invalidate on the statuslabel itself because those methods are not available to it. What am I doing wrong?
ADDED INFO:
The "process" is started by a button click on the form which calls a method in a separate class that looks like this:
public void DoSomeProcess()
{
TriggerProcessStarted();
System.Threading.Thread.Sleep(2000); // For testing..
TriggerProcessComplete();
}
and inside the TriggerProcessxxxx methods I trigger the events using this code...
var EventListeners = EH.GetInvocationList(); //EH is the appropriate EventHandler
if (EventListeners != null)
{
for (int index = 0; index < EventListeners.Count(); index++)
{
var methodToInvoke = (EventHandler)EventListeners[index];
methodToInvoke.BeginInvoke(this, EventArgs.Empty, EndAsyncEvent, new object[] { });
}
}
Finally, I have added Application.DoEvents() to the updateStatusLabel method but it did not help. I am still getting the same result. Here is my update method.
private void updateStatusLabel(string text)
{
StatusLabel1.Text = text;
statusStrip1.Refresh();
Application.DoEvents();
}
So I guess the "processing" is taking place on the UI thread but eventhandler is invoked on it's own thread which then invokes the control update back on the UI thread. Is this a dumb way of doing things? Note: The class that contains the DoSomeProcess() method is in a separate .NET ClassLibrary that i am referencing.
If you're doing your processing on the UI thread, it won't be able to do anything else (like redraw updated labels) while the processing is running. So for instance, if the processing is happening because the user clicked a button and is triggered by the button click handler (without explicitly placing it on another thread), it's running on the UI thread. Even though you update the label's text, it doesn't get drawn until it receives a paint message, at which point it's probably busy doing your processing.
The answer is to do long-running processing on a separate thread. The hack (IMHO) is to use Application.DoEvents to let the UI thread do some UI stuff during your processing. If you put one of those after updating the label and before you start your processing, odds are pretty high the label will get repainted. But then, during the processing, no further paint events can get processed (leading to half-drawn windows when someone moves another app window over your app and back, etc.). Hence my calling it a hack (even though, er, um, I've been known to do it :-) ).
Edit Update based on your edits:
Re
So I guess the "processing" is taking place on the UI thread but eventhandler is invoked on it's own thread...
I'm assuming DoSomeProcess is triggered from the UI thread (e.g., in direct response to a button click or similar). If so, then yes, your processing is definitely on the UI thread. Because TriggerProcessStarted triggers your callback asynchronously via BeginInvoke, you have no idea when it will run, but in any case your code then immediately launches into processing, never yielding, so no one else is going to be able to grab that thread. Since that's the UI thread, the call to the delegate will block on the Invoke call setting the label's text, whereupon it has to wait for the UI thread (which is busy processing). (And that's assuming it's scheduled on a different thread; I couldn't 100% convince myself either way, because Microsoft has two different BeginInvokes -- which IIRC one of the designers has acknowledged was a Really Dumb Idea -- and it's been a while since I fought with this stuff.)
If you make the TriggerProcessStarted calls to your callbacks synchronous, you should be okay. But ideally, schedule the processing (if it's not doing UI) on its own thread instead.