Multithreading design question

  • Thread starter Thread starter dixp
  • Start date Start date
D

dixp

I'm new to writing multithreaded apps and I have a design question. I
have a winforms app and a class which has a method that does processing
which is time intensive. I want the user to be able to kick off the
process and continue to work in the appliaction while getting progress
updates and the ability to cancel. The method that seems easiest to me
is this:

The class exposes certain events for progress. Start, ProgressUpdate,
and End. Create an EventArgs class for passing data to the handlers.
The form has an instance of this class with handlers for these events.
When the user clicks go, a new thread kicks off that calls the method
on the class to do processing.
The method in the class raises the events at the appropriate time. The
ui thread traps those events and updates the UI accordingly. The
processing method in the class checks a variable after each chunk of
processing to see if the user wants to cancel and raises the
ProgressUpdate event. If the user clicks cancel in the form, the
cancel member of the class instance is set to indicate the user's
request and execution ends after the latest chunck of processing is
complete.

Since I'm new to multithreading, I'm unsure if this is a decent way to
make everything work. Is this a solid design or am I commiting
horrible crimes against the multithreading gods?

Paul
 
Paul,

That is an acceptable approach. However, you need to be aware of some
of the pitfalls inherent in multithreading programming especially when
Windows Forms are involved.

Threading in Windows Forms:
<http://www.yoda.arachsys.com/csharp/threads/winforms.shtml>

Shutting Down Worker Threads Gracefully
<http://www.yoda.arachsys.com/csharp/threads/shutdown.shtml>

Notice Jon's use of the ISynchronizeInvoke.BeginInvoke method in his
article "Threading in Windows Forms". That's the most important part.
Now, since you have a separate class that handles the long processing I
suggest you design it similar to the way Microsoft designed the
System.Timers.Timer class. That timer exposes a SynchronizingObject
property that takes an ISynchronizeInvoke which it uses to
automatically marshal its events on the thread hosting the
synchronizing object (which is usually the UI thread). For example:

public class IntensiveComputation
{
private ISynchronizeInvoke _Synchronizer = null;

public ISynchronizeInvoke SynchronizingObject
{
get { return _Synchronizer; }
set { _Synchronizer = value; }
}

public void Start()
{
// Start a thread here to run LongRunningMethod.
}

private void LongRunningMethod()
{
while (!done)
{
RaiseProgressUpdate(this, new EventArgs());
}
}

private void RaiseProgressUpdate(object sender, EventArgs args)
{
if (_Synchronizer != null && _Synchronizer.InvokeRequired)
{
// This recalls the current method, but on the desired thread.
Delegate m = new EventHandler(this.RaiseProgressUpdate);
object[] a = new object[] { sender, args };
_Synchronizer.BeginInvoke(m, a);
}
else
{
// Now we can actually raise the event.
if (ProgressUpdate != null)
{
ProgressUpdate(sender, args);
}
}
}
}

When the SynchronizingObject property is set to a Form or Control the
class automatically marshals ProgressUpdate on the UI thread, otherwise
the event is executed on the worker thread. You can use this pattern
for the Start and End events as well. This is a nice way of
encapsulating the marshaling logic. Be sure to read Jon's other
article on stopping worker threads gracefully.

Brian
 
Back
Top