I’ve got to call a routine from a supplied DLL. This DLL takes 2 to 10 minutes to run, depending on the speed of the PC it is being run on.
I have put the DLL call into a BackgroundWorker thread so that the interface will remain responsive.
private object Load(string feature) {
object result = null;
using (var w = new BackgroundWorker()) {
w.WorkerReportsProgress = true;
w.WorkerSupportsCancellation = true;
w.DoWork += delegate(object sender, DoWorkEventArgs e) {
e.Result = DAL.get(feature);
};
w.RunWorkerCompleted += delegate(object sender, RunWorkerCompletedEventArgs e) {
progressBar1.Visible = false;
if (e.Error != null) {
MessageBox.Show(this, e.Error.Message, "Load Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
} else {
result = e.Result;
}
};
w.RunWorkerAsync();
if (w.IsBusy) {
progressBar1.Style = ProgressBarStyle.Marquee;
progressBar1.Visible = true;
}
}
return result;
}
This works, but I can’t call this method inline with other calls that are waiting on its results because it will immediately return a null value.
So, I stuck in a ManualResetEvent instance to try and get the method to wait until it actually had a value before returning:
private object Load(string feature) {
object result = null;
using (var w = new BackgroundWorker()) {
var mre = new ManualResetEvent(false);
w.WorkerReportsProgress = true;
w.WorkerSupportsCancellation = true;
w.DoWork += delegate(object sender, DoWorkEventArgs e) {
e.Result = DAL.get(feature);
};
w.RunWorkerCompleted += delegate(object sender, RunWorkerCompletedEventArgs e) {
progressBar1.Visible = false;
if (e.Error != null) {
MessageBox.Show(this, e.Error.Message, "Model Load Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
} else {
result = e.Result;
}
mre.Set();
};
w.RunWorkerAsync();
if (w.IsBusy) {
progressBar1.Style = ProgressBarStyle.Marquee;
progressBar1.Visible = true;
progressBar1.Value = 0;
const string statusRun = @"\|/-";
const string statusMsg = "Loading Data...";
int loops = 0;
do {
int index = loops++ % 4;
tsStatus.Text = statusMsg + statusRun[index].ToString(); // '\', '|', '/', '-'
} while (!mre.WaitOne(200));
}
}
return result;
}
However, it appears that doing this causes all of my CPU time to be spent on the ManualResetEvent’s WaitOne method and the Set() trigger is never called.
Has anyone encountered this behavior before and found a good workaround for it?
I have created a workaround for it in the past, but it involved creating a second thread to run the WaitOne method so that the first thread can process the DoWork code.
That is why the
asyncandawaitkeywords were invented. There is no easy solution for this that doesn’t block the thread.Since the DLL you are using apparently does not supply methods implemented using any of the Asynchronous Programming Patterns (like
BeginOperation/EndOperation, or Task-Based Async Programming), you’re stuck with a separate worker thread.What you can do is:
Start your
BackgroundWorkerorThreadas usual, then return immediately. Do not continue with the operation which would have required the return value of the lengthy DLL process. Once theBackgroundWorkerorThreadis finished, have it report progress, and in theProgressChangedevent handler, you can retrieve the result of the lengthy DLL process and continue with the operation. Alternatively you can use theRunWorkerCompletedevent (might actually be a better choice).In the meantime, you may have to disable all controls which could start the lengthy DLL process again, or which would otherwise issue invalid operations while the process is running. And as Henk Holterman wrote, do not dispose the
BackgroundWorkerlike that.