I have the following code. It is just a form app. On load it will run the bacground worker.
Then I have a button that is supposed to stop the infinite loop in the background worker by setting a flag to true.
I'm logging the out put of the backgroundworker1.IsBusy and it says it is busy but according to the logic in my code it shouldn't be busy because I set the flag to true thus exiting the while loop and running the backgroundworker_Completed event.
I must be doing something wrong but I can not figure it out.
If I'm approaching this incorrectly could somebody either help me fix what I'm doing wrong or point me in a better direction on how I can accomplish what I"m trying to do here.
private volatile bool StopScanning = false;
private void myForm_Load(object sender, EventArgs e)
{
try
{
if (backgroundWorker1.IsBusy)
{
//do nothing
}
else
{
backgroundWorker1.RunWorkerAsync();
}
}
catch (Exception boo)
{
Log.log(boo.ToString());
}
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
while (StopScanning == false)
{
Application.DoEvents();
try
{
ReturnScannedItems();
System.Threading.Thread.Sleep(1000);
}
catch (Exception boo)
{
Log.log(boo.ToString());
}
}
}
private void cancelbutton_Click(object sender, EventArgs e)
{
try
{
Log.log("Setting Stop Scan flag to true");
StopScanning = true;
Log.log(CloseScanSession().ToString());
}
catch (Exception boo)
{
Log.log("Setting Stop Scan flag to true");
StopScanning = true;
Log.log(CloseScanSession().ToString());
Log.log(boo.ToString());
}
while (backgroundWorker1.IsBusy)
{
Log.log("Still busy");
}
this.Close();
}
You are blocking the UI thread, which prevents the BackgroundWorker from completing. It can't raise the RunWorkerCompleted event until the UI thread is free to process new messages (raising the event involves posting a message to the UI thread's message queue, so that the UI thread can then execute the code that will actually raise the event).
Your code also is flawed in that it's calling Application.DoEvents() from the worker thread. You should never call this method anyway, but it's particularly foolish to call it from a worker thread, because the whole point of having a worker thread is to avoid having to call that method (and it won't do anything when called on the worker thread anyway, because the worker thread shouldn't own any window objects that would need to receive a window message).
Instead of sitting in a busy loop, checking IsBusy and blocking the UI thread, you should just subscribe to the RunWorkerCompleted event and do whatever you need to do there. Without a good Minimal, Complete, and Verifiable code example that fully illustrates what you're actually trying to do, it's not possible to provide any more specific advice than that.
i use background worker to call method but in return give me an Exception here is the code
private void Button_Click(object sender, RoutedEventArgs e)
{
BGW.RunWorkerAsync();
}
void BGW_DoWork(object sender, DoWorkEventArgs e)
{
e.Result = new Drug_Class().Search(Filter);
}
class Drug_Class
{
public List<WorkSpaceVariable.Drug_List> Search(Expression<Func<db.Drug_Catalog, bool>> Filter)
{
using (db.PVDBDataContext PVDB=new PVDBDataContext ())
{
try
{
var DQuary = from D in PVDB.Drug_Catalogs.Where(Filter)
select new WorkSpaceVariable.Drug_List
{
Drugs_ID = D.Drugs_ID
}
return DQuary.ToList() ;//Exception The calling thread cannot access this object because a different thread owns it.
}
catch (Exception E)
{
return null;
}
}
}
i don't understand why i got this Exception may any one tell me whats wrong with my code ?
The Exception that you got really explains your problem... all you need to do is to read it:
The calling thread cannot access this object because a different thread owns it.
You should hopefully know that a BackgroundWorker works on a background thread, so you should be able to work out that the two threads mentioned would be this background thread and the main UI thread.
What it means is that you cannot manipulate UI objects that were declared on (and therefore owned by) the main UI thread on any other thread.
The solution is to not manipulate UI objects from the UI thread in your background thread. Instead, just manipulate the data in the background thread and when the BackgroundWorker has finished, then update the UI element by updating the data bound collection.
I use Semaphore In this code
static Semaphore s = new Semaphore(1,1);
private void button2_Click(object sender, EventArgs e)
{
Thread[] t = new Thread[full_list];
for(int i=0;i<full_list;i++)
{
if (sorted_list[i].audio_node != null)
if (sorted_list[i].audio_node.Checked == true)
{
t[i] = new Thread(DownloadFile);
t[i].Start(sorted_list[i]);
}
}
}
private void DownloadFile(object a)
{
s.WaitOne();
if (InvokeRequired)
{
BeginInvoke(new DownloadFileDelegate(DownloadFile),new object[1] {a} );
return;
}
else
{
download process....
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
}
s.Release();
}
But it doesn't work, my prorgram freezes. I am trying solve this problem, but i don't know why it doesn't work with Semaphore. All components include downloading work correctly.
You're running DownloadFile on a non-gui thread. In the method you acquire the semaphore, and then call InvokeRequired. It will return true as you're not on the gui thread, so you're invoke DownloadFile on the gui thread. You then return without releasing the semaphore, so whenDownloadFile` runs on the gui thread the first thing it will try to do is acquire the semaphore, and because it can't it will block.
There's not much point in creating a thread in your code that is just going to schedule a call back on the gui thread. What you really need to do is download the file on the non-gui thread, and then when you've got it make a call back onto the gui thread to handle what you've downloaded.
Regarding the semaphore, you should wrap the code in a try\finally block to make sure it's always released, even if you've got a return in the middle of the code:
s.WaitOne();
try
{
// Rest of method
}
finally
{
s.Release();
}
I have a Thread that starts in my main form
private void changePasswordbutton_Click_1(object sender, EventArgs e)
{
waitForm.Show();
Thread thread = new Thread(ProcessInkPresenter);
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
thread.Join();
waitForm.Hide();
waitForm.Dispose();
}
I want to close the waitForm inside the ProcessInkPresenter method (which is running on a thread) instead of waiting for the thread to complete.
How do I do this?
Thanks
Method signatures
private void ProcessInkPresenter()
Defined in the class header
Wait waitForm;
Your original code doesn't make sense. It shows a form, then starts a thread, then waits for that thread to complete. If you want the form to be run on it's own UI thread, have ProcessInkPresenter run on the same UI thread (which it should if it interacts with the UI) and have the form closed and be disposed of when ProcessInkPresenter completes, try this:
private void changePasswordbutton_Click_1(object sender, EventArgs e)
{
Thread thread = new Thread(state => {
using (var waitForm = new WaitForm()) {
waitForm.Activated += (s, e) => {
ProcessInkPresenter();
waitForm.Hide();
}
Application.Run(waitForm);
}
}
);
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
}
If the worker thread does not have to interact with the GUI, then what you want is something like the following. Note that I make use of Invoke to make sure that the interaction with the UI is done on the UI thread. There is no need to check InvokeRequired here, since I already know for sure that I am on a background thread.
If you want to keep the same waitForm instance:
private void changePasswordbutton_Click_1(object sender, EventArgs e)
{
Thread thread = new Thread(state => {
try {
ProcessInkPresenter();
// If ProcessInkPresenter fails, this line will never execute
waitForm.Invoke(new Action(()=>waitForm.Hide()));
}
catch (Exception ex) {
// You probably want to do something with ex here,
// rather than just swallowing it.
}
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
waitForm.Show();
}
NOTE: It doesn't make sense to dispose your WaitForm if you have a single instance of it (your Wait instance). Either construct an instance each time you use it, or never dispose it and use .Hide() instead.
When my C# application closes it sometimes gets caught in the cleanup routine. Specifically, a background worker is not closing. This is basically how I am attempting to close it:
private void App_FormClosing(object sender, FormClosingEventArgs e)
{
backgroundWorker1.CancelAsync();
while (backgroundWorker1.IsBusy) ; // Gets stuck here.
}
Is there a different way that I should be doing this? I am using Microsoft Visual C# 2008 Express Edition. Thanks.
ADDITIONAL INFORMATION:
The background worker does not appear to be exiting. This is what I have:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
while (!backgroundWorker1.CancellationPending)
{
// Do something.
}
}
I've also modified the cleanup code:
private void App_FormClosing(object sender, FormClosingEventArgs e)
{
while (backgroundWorker1.IsBusy)
{
backgroundWorker1.CancelAsync();
System.Threading.Thread.Sleep(1000);
}
}
Is there something else that I should be doing?
Some pretty good suggestions, but I don't believe they address the underlying issue: canceling a background task.
Unfortunately, when using BackgroundWorker, termination of your task depends on the task itself. The only way your while loop will terminate, is if your background task checks its Cancel property and returns or breaks from its current process.
Example Base
For example, consider
private readonly BackgroundWorker worker = new BackgroundWorker ();
public void SomeFormEventForStartingBackgroundTask ()
{
worker.DoWork += BackgroundTask_HotelCalifornia;
worker.WorkerSupportsCancellation = true;
worker.RunWorkerAsync ();
}
// semantically, you want to perform this task for lifetime of
// application, you may even expect that calling CancelAsync
// will out and out abort this method - that is incorrect.
// CancelAsync will only set DoWorkEventArgs.Cancel property
// to true
private void BackgroundTask_HotelCalifornia (object sender, DoWorkEventArgs e)
{
for ( ; ;)
{
// because we never inspect e.Cancel, we can never leave!
}
}
private void App_FormClosing(object sender, FormClosingEventArgs e)
{
// [politely] request termination
worker.CancelAsync();
// [politely] wait until background task terminates
while (worker.IsBusy);
}
This is what is happening by default. Now, maybe your task isn't an infinite loop, perhaps it is just a long-running task. Either way, your main thread will block [actually it is spinning, but whatevs] until the task completes, or doesn't as the case may be.
If you have personally written and can modify the task, then you have a few options.
Example Improvement
For instance, this is a better implementation of the above example
private readonly BackgroundWorker worker = new BackgroundWorker ();
// this is used to signal our main Gui thread that background
// task has completed
private readonly AutoResetEvent isWorkerStopped =
new AutoResentEvent (false);
public void SomeFormEventForStartingBackgroundTask ()
{
worker.DoWork += BackgroundTask_HotelCalifornia;
worker.RunWorkerCompleted += BackgroundTask_Completed;
worker.WorkerSupportsCancellation = true;
worker.RunWorkerAsync ();
}
private void BackgroundTask_HotelCalifornia (object sender, DoWorkEventArgs e)
{
// execute until canceled
for ( ; !e.Cancel;)
{
// keep in mind, this task will *block* main
// thread until cancel flag is checked again,
// so if you are, say crunching SETI numbers
// here for instance, you could still be blocking
// a long time. but long time is better than
// forever ;)
}
}
private void BackgroundTask_Completed (
object sender,
RunWorkerCompletedEventArgs e)
{
// ok, our task has stopped, set signal to 'signaled' state
// we are complete!
isStopped.Set ();
}
private void App_FormClosing(object sender, FormClosingEventArgs e)
{
// [politely] request termination
worker.CancelAsync();
// [politely] wait until background task terminates
isStopped.WaitOne ();
}
While this is better, it's not as good as it could be. If you can be [reasonably] assured your background task will end, this may be "good enough".
However, what we [typically] want, is something like this
private void App_FormClosing(object sender, FormClosingEventArgs e)
{
// [politely] request termination
worker.CancelAsync();
// [politely] wait until background task terminates
TimeSpan gracePeriod = TimeSpan.FromMilliseconds(100);
bool isStoppedGracefully = isStopped.WaitOne (gracePeriod);
if (!isStoppedGracefully)
{
// KILL! KILL! KILL!
}
}
Alas, we cannot. BackgroundWorker does not expose any means of forceful termination. This is because it is an abstraction built on top of some hidden thread management system, one which could potentially destabalize other parts of your application if it were forcefully terminated.
The only means [that I have seen at least] to implement the above is to manage your own threading.
Example Ideal
So, for instance
private Thread worker = null;
// this time, 'Thread' provides all synchronization
// constructs required for main thread to synchronize
// with background task. however, in the interest of
// giving background task a chance to terminate gracefully
// we supply it with this cancel signal
private readonly AutoResetEvent isCanceled = new AutoResentEvent (false);
public void SomeFormEventForStartingBackgroundTask ()
{
worker = new Thread (BackgroundTask_HotelCalifornia);
worker.IsBackground = true;
worker.Name = "Some Background Task"; // always handy to name things!
worker.Start ();
}
private void BackgroundTask_HotelCalifornia ()
{
// inspect cancel signal, no wait period
//
// NOTE: so cheating here a bit, this is an instance variable
// but could as easily be supplied via parameterized thread
// start delegate
for ( ; !isCanceled.WaitOne (0);)
{
}
}
private void App_FormClosing(object sender, FormClosingEventArgs e)
{
// [politely] request termination
isCanceled.Set ();
// [politely] wait until background task terminates
TimeSpan gracePeriod = TimeSpan.FromMilliseconds(100);
bool isStoppedGracefully = worker.Join (gracePeriod);
if (!isStoppedGracefully)
{
// wipe them out, all of them.
worker.Abort ();
}
}
And that there, is a decent introduction on thread management.
Which is best suited for you? Depends on your application. It is probably best not to rock the boat, and modify your current implementation to ensure that
your background task inspects and respects the Cancel property
your main thread waits for completion, as opposed to polling
It is very important to compare and evaluate the pros and cons of each approach.
If you must control and guarantee termination of someone else's tasks, then writing a thread management system that incorporates the above may be the way to go. However you would lose out on out-of-box features like thread pooling, progress reporting, cross-thread data marshalling [worker does that, no?], and a bunch of other stuff. Not to mention, "rolling your own" is often error prone.
Anyway, hope this helps :)
Kevin Gale is correct in stating that your BackgroundWorker's DoWork handler needs to poll for CancellationPending and return if a cancellation is requested.
That being said, if this is happening when your application is shutting down, you can just ignore it safely, as well. BackgroundWorker uses a ThreadPool thread, which is, by definition, a background thread. Leaving this running will not prevent your application from terminating, and the thread will automatically be torn down when your application shuts down.
In the background worker thread you need to check the BackgroundWorker.CancellationPending flag and exit if it is true.
The CancelAsync() just sets this flag.
Or to put it another way. CancelAsync() doesn't actually cancel anything. It won't abort the thread or cause it to exit. If the worker thread is in a loop and checks the CancellationPending flag periodically it can catch the cancel request and exit.
MSDN has an example here although it doesn't use a loop in the worker routine.
This code is guaranteed to deadlock when the BGW is still running. BGW cannot complete until its RunWorkerCompleted event finished running. RunWorkerCompleted cannot run until the UI thread goes idle and runs the message loop. But the UI thread isn't idle, it is stuck in the while loop.
If you want the BGW thread to complete cleanly, you have to keep your form alive. Check this thread to see how to do that.
Try:
if (this.backgroundWorker1.IsBusy) this.backgroundWorker1.CancelAsync();