delegate void UpdateProgressDelegate(int progress);

public void UpdateProgressBar(int progress)

{

if (this.InvokeRequired == false)

{

this.progressBarDownload.Value = progress;

}

else

{

this.Invoke(new UpdateProgressDelegate(UpdateProgressBar), new object[] { progress });

}

}

The new implementation is intended to replace this code and support the original ThreadBarrier concept.

Introducing the DelegateMarshaler

The DelegateMarshaler implementation is virtually identical to the ThreadBarrier except for four minor differences:

1. The marshaler is created using a static method DelegateMarshaler.Create() so an exception can be thrown if no SynchronizationContext exists (console app, or before UI is started, etc.)
2. If the calling thread is already the target thread (UI thread), then the delegate is invoked normally rather than a cross thread invoke. This is similar to InvokeRequired being false.
3. The DelegateMarshaler supports methods with 0 to 4 arguments.
4. Static methods wrap ThreadPool.QueueUserWorkItem in a type safe way.

A compact example

void buttonDownload_Click(object sender, EventArgs e)

{

DelegateMarshaler marshaler = DelegateMarshaler.Create();

DelegateMarshaler.QueueOnThreadPoolThread(

(fileName) =>

{

//simulate download

for (int i = 0; i < 100; ++i)

{

marshaler.Invoke(UpdateProgressBar, i);

Thread.Sleep(50);

}

marshaler.Invoke(ShowDownloadComplete, fileName);

},

“somefile.txt”);

}

private void UpdateProgressBar(int progress)

{

this.progressBarDownload.Value = progress;

}

private void ShowDownloadComplete(string fileName)

{

this.labelFileDownload.Text = fileName;

}

Using the DelegateMarshaler consists of creating the marshaler on the UI thread and invoking the methods that update the UI (preferably from the worker thread). Invoke will call the method synchronously, and BeginInvoke will call the method asynchronously allowing the worker to continue running while the UI updates. If your thread is a separate method altogether (which is usually the case), you would want to save the DelegateMarshaler instance as a private field in your form or control so it can be used in the thread method.

The DelegateMarshaler Implementation

public sealed class DelegateMarshaler

{

private SynchronizationContext _synchronizationContext;

public static DelegateMarshaler Create()

{

if (SynchronizationContext.Current == null)

{

throw new InvalidOperationException(“No SynchronizationContext exists for the current thread.”);

}

return new DelegateMarshaler(SynchronizationContext.Current);

}

private DelegateMarshaler(SynchronizationContext synchronizationContext)

{

this._synchronizationContext = synchronizationContext;

}

private bool IsMarshalRequired

{

get

{

return this._synchronizationContext != SynchronizationContext.Current;

}

}

public void Invoke<T>(Action<T> action, T arg)

{

if (this.IsMarshalRequired == false)

{

// already on the target thread, just invoke delegate directly

action(arg);

}

else

{

// marshal the delegate call to the target thread

this._synchronizationContext.Send(delegate { action(arg); }, null);

}

}

//simplifies use of threadpool so arguments do not need to be cast

public static void QueueOnThreadPoolThread<T>(Action<T> action, T arg)

{

ThreadPool.QueueUserWorkItem(delegate { action(arg); });

}

}

It is such a small class, feel free to modify it to fit your needs. Download the sample for the complete code and comments:

DelegateMarshalerSample

Notable Links
http://thevalerios.net/matt/2008/05/a-type-safe-backgroundworker-wrapper/
http://weblogs.asp.net/justin_rogers/articles/126345.aspx
http://www.codeproject.com/KB/cs/AOPInvokeRequired.aspx

Update – ThreadBarrier was a poorly chosen name, use the latest DelegateMarshaler implementation instead.

Previously I introduced the ThreadBarrier pattern which describes a simple technique for allowing worker threads to easily and safely communicate with controls on the UI thread. The key points from the previous article are:

A worker thread is completely contained within a class (and any objects the class references)

1. Events from this worker class are raised on the UI thread
2. A SynchronizationContext is used rather than Control.Invoke or Dispatcher.Invoke
3. The UI code does not have to worry about what thread is executing, it always assumes the UI thread (keeps code clean)
4. The ThreadBarrier needs to be created on a UI thread to capture the UI’s SynchronizationContext

Today’s article is a revisitation of the pattern to demonstrate several ways the technique can be used, as well as describe the flaw in the previous implementation. Yesterday’s article on events and threads provides an in depth background on the subtleties of events and multithreading. The contents of today’s post include:

• The New ThreadBarrier Code
• Sample UI and Worker Classes
• ThreadBarrier Technique #1: Subclassing an existing worker thread class
• ThreadBarrier Technique #2: Using extension methods on a SynchronizationContext
• ThreadBarrier Technique #3: Deriving from a ThreadBarrier
• ThreadBarrier Technique #4: Creating an instance of a ThreadBarrier
• ThreadBarrier Technique #5: Creating an adapter class to propagate events
• The Original ThreadBarrier Implementation Flaw
• ThreadBarrier FAQ

Download the examples.

The New ThreadBarrier Code

.NET 2.0

public class ThreadBarrier

{

private SynchronizationContext _synchronizationContext;

public ThreadBarrier()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

}

public void Post<T>(Action<T> raiseEventMethod, T e)

where T : EventArgs

{

if (this._synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem(delegate { raiseEventMethod(e); });

}

else

{

this._synchronizationContext.Post(delegate { raiseEventMethod(e); }, null);

}

}

}

.NET 3.5

public static class ThreadBarrierExtensions

{

public static void Post<T>(this SynchronizationContext synchronizationContext, Action<T> raiseEventMethod, T eventArgs)

where T : EventArgs

{

if (synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem((e) => raiseEventMethod((T)e), eventArgs);

}

else

{

synchronizationContext.Post((e) => raiseEventMethod((T)e), eventArgs);

}

}

}

The use of an anonymous delegate can be used for either implementation. The .NET 3.5 version uses a lambda expression just to demonstrate an alternate way of invoking the action.

Sample UI and Worker Classes

The sample UI and worker classes are very simple examples that will be the reference code for the techniques that follow. The UI code remains virtually unchanged throughout every technique which is ideal since it should not be concerned with threading:

These classes do not work together as is, they need a ThreadBarrier.

Sample Worker Class

public class WeatherChecker

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

public event EventHandler<WeatherEventArgs> HumidityChanged;

public event EventHandler<WeatherEventArgs> WindChanged;

public event EventHandler Stopped;

private bool _isStopRequested;

private Random _random;

public WeatherChecker()

{

this._isStopRequested = false;

//used for generating random weather information

this._random = new Random((int)DateTime.Now.Ticks);

}

public void Start()

{

Thread thread = new Thread(new ThreadStart(CheckWeather));

thread.IsBackground = true; //prevents thread from keeping app alive when app is closed

thread.Start();

}

private void CheckWeather()

{

while (this._isStopRequested == false)

{

OnTemperatureChanged(new WeatherEventArgs(Rand(30f)));

OnWindChanged(new WeatherEventArgs(Rand(15f)));

OnHumidityChanged(new WeatherEventArgs(Rand(100f)));

//Updates roughly 4 times per second

Thread.Sleep(250);

}

OnStopped(EventArgs.Empty);

}

public void RequestStop()

{

this._isStopRequested = true;

}

private float Rand(float max)

{

return (float)this._random.NextDouble() * max;

}

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

protected virtual void OnHumidityChanged(WeatherEventArgs e)

{

if (this.HumidityChanged != null)

{

this.HumidityChanged(this, e);

}

}

protected virtual void OnWindChanged(WeatherEventArgs e)

{

if (this.WindChanged != null)

{

this.WindChanged(this, e);

}

}

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

}

Sample UI Class

public partial class Form1 : Form

{

private WeatherChecker _weatherChecker;

public Form1()

{

InitializeComponent();

}

private void buttonStart_Click(object sender, EventArgs e)

{

this.buttonStart.Enabled = false;

this.buttonStop.Enabled = true;

this._weatherChecker = new WeatherChecker();

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

this._weatherChecker.HumidityChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_HumidityChanged);

this._weatherChecker.WindChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_WindChanged);

this._weatherChecker.Stopped += new EventHandler(_weatherChecker_Stopped);

this._weatherChecker.Start();

}

private void buttonStop_Click(object sender, EventArgs e)

{

this._weatherChecker.RequestStop();

}

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

this.labelTemperature.Text = String.Format(“{0:F1} C”, e.Value);

}

void _weatherChecker_HumidityChanged(object sender, WeatherEventArgs e)

{

this.labelHumidity.Text = String.Format(“{0:F0}%”, e.Value);

}

void _weatherChecker_WindChanged(object sender, WeatherEventArgs e)

{

this.labelWind.Text = String.Format(“{0:F0} mph”, e.Value);

}

void _weatherChecker_Stopped(object sender, EventArgs e)

{

this.buttonStop.Enabled = false;

this.buttonStart.Enabled = true;

this._weatherChecker = null;

}

}

ThreadBarrier Technique #1: Subclassing an existing worker thread class

The two classes above are doing nothing special to communicate with on another. An attempt to use the two together would fail since the worker class is raising events on the worker thread which is not allowed to access controls on the UI thread. Amazingly using a ThreadBarrier in the following way causes all events from the worker class to be automatically raised on the UI thread:

public class ThreadBarrierWeatherChecker : WeatherChecker

{

private ThreadBarrier _threadBarrier;

public ThreadBarrierWeatherChecker()

{

this._threadBarrier = new ThreadBarrier();

}

protected override void OnTemperatureChanged(WeatherEventArgs e)

{

this._threadBarrier.Post(base.OnTemperatureChanged, e);

}

protected override void OnWindChanged(WeatherEventArgs e)

{

this._threadBarrier.Post(base.OnWindChanged, e);

}

protected override void OnHumidityChanged(WeatherEventArgs e)

{

this._threadBarrier.Post(base.OnHumidityChanged, e);

}

protected override void OnStopped(EventArgs e)

{

this._threadBarrier.Post(base.OnStopped, e);

}

}

That’s it! All it took was deriving from the worker class and posting the method that raises the events to the UI thread. The UI class should create an instance of ThreadBarrierWeatherChecker rather than WeatherChecker. This technique is handy if you do not own or can’t modify the code to the worker class.

ThreadBarrier Technique #2: Using extension methods on a SynchronizationContext

This technique requires the developer to not only have access to the WeatherChecker code, but also capture the UI’s SynchronizationContext in the WeatherChecker’s constructor:

private SynchronizationContext _synchronizationContext;

public WeatherChecker()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

…

}

Raising events now uses the _synchronizationContext field and the ThreadBarrier extension method:

this._synchronizationContext.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

this._synchronizationContext.Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

this._synchronizationContext.Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

ThreadBarrier Technique #3: Deriving from a ThreadBarrier

Again if the developer is in full control of the worker class, all that it takes is deriving from a ThreadBarrier to inherit the method that provides the posting to the UI thread:

public class WeatherChecker : ThreadBarrier

Raising the events is now a matter of calling the Post method in the base ThreadBarrier class:

Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

In order for the ThreadBarrier to work the WeatherChecker class needs to be created on the UI thread so the base ThreadBarrier class can capture the UI’s SynchronizationContext.

ThreadBarrier Technique #4: Creating an instance of a ThreadBarrier

If deriving from a ThreadBarrier is not an option, just creating an instance of a ThreadBarrier will work as well. This implementation is similar to the extension method sample, but the ThreadBarrier instance will hide the capturing and storing of the SynchronizationContext. This technique also requires the WeatherChecker to be created on the UI thread.

private ThreadBarrier _threadBarrier;

public WeatherChecker()

{

this._threadBarrier = new ThreadBarrier();

…

}

this._threadBarrier.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

this._threadBarrier.Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

this._threadBarrier.Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

ThreadBarrier Technique #5: Creating an adapter class to propagate events

This technique should be a last resort for the scenario where you can’t derive from the worker class and you are unable to modify its code. Since an extra set of events need to be created and subscribed, it can be dangerous and lead to memory leaks if the handlers are not properly removed.

Adapter Class (extra events removed for compactness)

public class ThreadBarrierWeatherChecker : ThreadBarrier

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

…

private WeatherChecker _weatherChecker;

public ThreadBarrierWeatherChecker()

{

}

public void Attach(WeatherChecker weatherChecker)

{

this._weatherChecker = weatherChecker;

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

…

}

public void Detach()

{

this._weatherChecker.TemperatureChanged -= new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

…

this._weatherChecker = null;

}

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

Post(OnTemperatureChanged, e);

}

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

}

The adapter class needs to provide a way to attach and detach to an already existing WeatherChecker instance. If the instance is not detached, it will result in a memory leak (the adapter class will be kept alive).

The Original ThreadBarrier Implementation Flaw

The first implementation of the ThreadBarrier used the event as a parameter:

protected void PostEvent<T>(EventHandler<T> eventHandler, object sender, T eventArgs)

where T : EventArgs

{

//do not raise the event if none was provided

if (eventHandler == null)

{

return;

}

this._synchronizationContext.Post(delegate { eventHandler(this, eventArgs); }, null);

}

The problem with this implementation is that the event handler delegate is copied when passed to the method. During execution of this method (which occurs on the worker thread) a UI thread could remove the original handler and dispose of the UI control. Since the method’s copy of the delegate will still get posted to the UI thread, the handler will be executed in the control’s code even though the control was already disposed. In other words, if the worker class is being used by multiple windows or controls that are opening and closing it could lead to this problem. See Problem #2 in the Events and Threads post.

ThreadBarrier FAQ

Q: Why not just use AsynchOperationManager.SynchronizationContext in the base class for each method post?
A: Since the methods are originally called on the worker thread, it means the call to the AsynchOperationManager.SynchronizationContext static property will be made from the worker thread. It will thus return an ‘empty’ SynchronizationContext. The call to the static property must be made on the UI and the SynchronizationContext must be ’saved’ so the worker can use it.

Q: Why not just use SynchronizationContext.Current?
A: The static SynchronizationContext.Current returns null when called from a worker thread, while AsynchOperationManager.SynchronizationContext will at least return an empty SynchronizationContext so we at least have some context reference.

Q: What is the difference between a ThreadBarrier and BackgroundWorker?
A: The BackgroundWorker must also be created on a UI thread. However, the BackgroundWorker does not provide an easy and transparent way (other than ReportProgress) to post events and data from the worker to the UI thread. A ThreadBarrier will support any kind of event since it uses generics.

Q: Why not use WPF’s built in cross-thread binding support?
A: A ThreadBarrier can be used in combination with WPF’s cross-thread binding. The difference is that a ThreadBarrier (and events) allow arbitrary code in the UI to execute. Properties just represent data.

Download the examples.

Update – ThreadBarrier was a poorly chosen name, use the latest DelegateMarshaler implementation instead.

With the advent of multi-core processors becoming standard in desktop PCs, it is clear we are on the verge of a shift in which high level software is designed and developed. First there was Object Oriented programming, then design patterns, and now there is multithreading. Multithreading has been around for decades in high end computing, but due to the now wide availability of multiple cores in a standard PC or laptop, it is only now that it is beginning to gain mainstream attention. There is a lot of work to do for tools, frameworks, and patterns to simplify the design and debugging of multithreading programs. While Microsoft has been working diligently to improve their tools (Visual Studio) and frameworks (Task Parallel Library) to bring multithreading into the mainstream, there is not yet enough guidance and information on the internet about proper threading techniques and design patterns.

This is where the ‘ThreadBarrier’ pattern comes in. Ultimately it is a way to help simplify the interaction between the UI and worker threads. A ThreadBarrier is an encapsulation of thread execution inside a class such that it is not exposed to the outside world. Rather, external events are first posted to the UI thread so any listener (on the UI thread) does not have to worry about threading issues. Like any pattern, there are times where it is ideal to use and there are times where it does not apply. Use at your own discretion.

Background

It seems that nearly every introductory threading example on the internet consists of a button click that starts a thread that performs some operation in a worker thread in the UI code behind. While simple examples are good, this immediately introduces a developer to starting threads In UI code and thinking that such techniques are normal.

The Problem

The problem is that the only way most developers know how to get data back to the UI thread is to use a UI control to post back the information. In case you are new to threading: the golden rule is that all UI controls (windows, textboxes, progressbars, etc.) can only be accessed from the thread that created them (the UI thread of course). This means a worker thread cannot do myTextBox.Text=”asdf” otherwise a cross-thread exception will be thrown. Controls provide a mechanism for executing a method on the UI thread (Control.Invoke, Control.BeginInvoke, Dispatcher.Invoke, Dispatcher.BeginInvoke).

WinForms example:

delegate void SetStartDelegate(bool enabled);

public void SetStartEnabled(bool enabled)

{

if (this.InvokeRequired == false)

{

this.buttonStart.Enabled = enabled;

}

else

{

this.Invoke(new SetStartDelegate(SetStartEnabled), new object[] { enabled });

}

}

WPF example:

delegate void SetStartDelegate(bool enabled);

public void SetStartEnabled(bool enabled)

{

if (this.Dispatcher.CheckAccess() == true)

{

this.buttonStart.IsEnabled = enabled;

}

else

{

this.Dispatcher.Invoke(DispatcherPriority.Send, new SetStartDelegate(SetStartEnabled), enabled);

}

}

There are tricks to make this a bit cleaner, but that is the common way to update the UI from any thread.

The combination of the Control’s UI thread rule and a Control’s ability to invoke on the UI thread essentially handcuffs developers into mixing threads with the UI and trying to make it work. Perhaps some have tried to be smart and hide the threads away deep in non-UI code to keep the UI clean. Those developers probably end up with the following questions (at least I did):

“How the heck do you get a control for invoking that deep in the execution and far away from the UI code? And more importantly, why does it have to be this way? There has to be a better way.”

The Answer

There is a better way, and it involves a SynchronizationContext. Rather than use a Control to post execution back to the UI, a SynchronizationContext provides this same capability without the UI Control requirement. Since a fantastic CodeProject article already covers the SynchronizationContext in depth, a summary will only be described here.

SynchronizationContext Overview

-SynchronizationContext is an abstract base class for:
-WindowsFormsSynchronizationContext
-DispatcherSynchronizationContext
-WinForms automatically creates an instance of WindowsFomsSynchronizationContext for a WinForms UI thread.
-WPF automatically creates an instance of DispatcherSynchronizationContext for a WPF UI thread.
-Static property AsyncOperationManager.SynchronizationContext gets the SynchronizationContext for the calling thread: WindowsFormsSynchronizationContext in WinForms and DispatcherSynchronizationContext in WPF.
-SynchronizationContext provides two methods (Send and Post) for synchronous or asynchronous method invocation.
-Getting AsyncOperationManager.SynchronizationContext on a non-UI thread (such as in a console app or worker thread) returns the base SynchronizationContext class that just invokes a method on the calling thread when Send is used, and calls a method on a ThreadPool thread when Post is used.

Introducing the ThreadBarrier ‘Pattern’

The ThreadBarrier pattern consists of a non-UI class encapsulating and executing a worker thread and always raising its events on the UI thread using a SynchronizationContext. The worker thread execution should never leave the class via events. Data and objects within the class may be operated upon by the worker thread but all external events must be called on the UI thread. If this technique is correctly followed then the listening UI code does not need to worry about thread checks and delegate posting.

Implementing a ThreadBarrier’ (.NET 2.0)

A ThreadBarrier can be implemented as an abstract class so that derived classes automatically inherit the necessary functionality to support the pattern.

public abstract class ThreadBarrier

{

private SynchronizationContext _synchronizationContext;

protected ThreadBarrier()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

}

The SyncronizationContext must be stored as a field so that it can be used by the worker thread in the derived class. Since the static AsyncOperationManager.SynchronizationContext property is called in the constructor, a critical requirement of properly using a ThreadBarrier derived class is that it must be created on the thread in which events want to be raised. In other words, create the class on the UI thread so that the UI’s context is captured. A worker thread can then use this context to post the methods that raise events back to the UI. The following protected method can be used for posting OnXXX methods:

public void Post<T>(Action<T> raiseEventMethod, T e)

where T : EventArgs

{

if (this._synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem(delegate { raiseEventMethod(e); });

}

else

{

this._synchronizationContext.Post(delegate { raiseEventMethod(e); }, null);

}

}

For an event such as:

public event EventHandler Stopped;

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

A ThreadBarrier derived class simply posts events to the UI in this way:

Post(OnStopped, EventArgs.Empty);

A small example of a class implementing a ThreadBarrier would look like:

public class WeatherChecker : ThreadBarrier

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

public event EventHandler<WeatherEventArgs> HumidityChanged;

public event EventHandler<WeatherEventArgs> WindChanged;

public event EventHandler Stopped;

private bool _isStopRequested;

private Random _random;

public WeatherChecker()

{

this._isStopRequested = false;

//used for generating random weather information

this._random = new Random((int)DateTime.Now.Ticks);

}

public void Start()

{

Thread thread = new Thread(new ThreadStart(CheckWeather));

thread.IsBackground = true; //prevents thread from keeping app alive when app is closed

thread.Start();

}

private void CheckWeather()

{

while (this._isStopRequested == false)

{

Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

//Updates roughly 4 times per second

Thread.Sleep(250);

}

Post(OnStopped, EventArgs.Empty);

}

public void RequestStop()

{

this._isStopRequested = true;

}

private float Rand(float max)

{

return (float)this._random.NextDouble() * max;

}

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

protected virtual void OnHumidityChanged(WeatherEventArgs e)

{

if (this.HumidityChanged != null)

{

this.HumidityChanged(this, e);

}

}

protected virtual void OnWindChanged(WeatherEventArgs e)

{

if (this.WindChanged != null)

{

this.WindChanged(this, e);

}

}

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

}

The key points are:
-WeatherChecker derives from ThreadBarrier
-The worker thread is started inside this non-UI WeatherChecker class.
-The WeatherChecker should be created on the UI thread.

Now the UI code is very clean and does not have to worry about threads:

public partial class Form1 : Form

{

private WeatherChecker _weatherChecker;

public Form1()

{

InitializeComponent();

}

private void buttonStart_Click(object sender, EventArgs e)

{

this.buttonStart.Enabled = false;

this.buttonStop.Enabled = true;

this._weatherChecker = new WeatherChecker();

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

this._weatherChecker.HumidityChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_HumidityChanged);

this._weatherChecker.WindChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_WindChanged);

this._weatherChecker.Stopped += new EventHandler(_weatherChecker_Stopped);

this._weatherChecker.Start();

}

private void buttonStop_Click(object sender, EventArgs e)

{

this._weatherChecker.RequestStop();

}

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

this.labelTemperature.Text = String.Format(“{0:F1} C”, e.Value);

}

void _weatherChecker_HumidityChanged(object sender, WeatherEventArgs e)

{

this.labelHumidity.Text = String.Format(“{0:F0}%”, e.Value);

}

void _weatherChecker_WindChanged(object sender, WeatherEventArgs e)

{

this.labelWind.Text = String.Format(“{0:F0} mph”, e.Value);

}

????????

void _weatherChecker_Stopped(object sender, EventArgs e)

{

this.buttonStop.Enabled = false;

this.buttonStart.Enabled = true;

this._weatherChecker = null;

}

}

Implementing a ThreadBarrier (.NET 3.5)

Since the requirement of deriving from a ThreadBarrier class is not ideal, in .NET 3.5 we can use extension methods to help us do the work.

public static class ThreadBarrierExtensions

{

public static void Post<T>(this SynchronizationContext synchronizationContext, Action<T> raiseEventMethod, T eventArgs)

where T : EventArgs

{

if (synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem((e) => raiseEventMethod((T)e), eventArgs);

}

else

{

synchronizationContext.Post((e) => raiseEventMethod((T)e), eventArgs);

}

}

}

Now the WeatherChecker class does not have to derive from a ThreadBarrier (but it now has to do the work in its constructor of saving a reference to the SynchronizationContext, the task previously left for the abstract ThreadBarrier class).:

public class WeatherChecker

{

private SynchronizationContext _synchronizationContext;

…

public WeatherChecker()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

…

}

Using an extension method on the SynchronizationContext allows us to post the OnXXX method:

this._synchronizationContext.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Using Lambda expressions also simplifies the handling of the events in the UI code:

this._weatherChecker.TemperatureChanged += (weatherChecker, weatherEventArgs) =>

{

this.labelTemperature.Content = String.Format(“{0:F1} C”, weatherEventArgs.Value);

};

Conclusion

The ThreadBarrier technique is an easy way to simplify the use of a worker thread and how it interacts with the UI. It is not the silver bullet for multithreading, but it does offer a way to think of a thread as an ‘object’ and hide the threading complexities. The UI and worker thread can be separated even further by designing a ThreadBarrier class to do nothing but handle events from other threading code (such as in a library that you do not have the code) and propagate just these events to the UI. This truly allows the business ‘logic’ to be free of any UI dependencies.

Samples

Download all Samples

UPDATE: The DelegateMarshaler has been revisited with a description of the 5 techniques in the sample.

m_TextBox.Invoke(new UpdateTextCallback(this.UpdateText), new object[]{”Text generated on non-UI thread.”});

WPF to the rescue
WPF has come to the rescue with its support for cross-thread property binding and notification. In other words, you can bind a progress bar’s current value to a property that gets changed on another thread. WPF will handle cross thread invoking automatically. This means it becomes very easy to design a WPF window that can not only display the progress of an operation, but also status text and other items that may be updated on the worker thread as an operation progresses, all without having to worry about invoking, callbacks, and threads.

Since most simple operations have the same pattern, a simple interface can be designed that simple operations can implement. We can then design a single WPF window that will display the progress of an operation by attaching to the interface rather than the simple operation:

Once the ProgressWindow and IProgressOperation classes are complete, many simple operations can be designed without having to worry about implementing another UI to display their progress. Here is an example of the IProgressOperation interface:

public interface IProgressOperation
{
int Total { get; }
int Current { get; }
void Start();
void CancelAsync();
event EventHandler ProgressChanged;
event EventHandler ProgressTotalChanged;
event EventHandler Complete;
}

Now we can implement a simple class that exports event logs, and implements this interface. Start() will start the BackgroundWorker, CancelAsync() will set a flag that the operation will check periodically, and the properties Total and Current provide the progress information needed for a progress display.

public void Start()
{
BackgroundWorker worker = new BackgroundWorker();
worker.DoWork += new DoWorkEventHandler(worker_DoWork);
worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);
worker.RunWorkerAsync();
}
public void CancelAsync()
{
this._isCancelationPending = true;
}
public int Current
{
get
{
return this._current;
}
private set
{
this._current = value;
OnProgressChanged(EventArgs.Empty);
}
}
void worker_DoWork(object sender, DoWorkEventArgs e)
{
this.Total = …
…
for (…)
{
//exit if the user cancels
if (this._isCancelationPending == true)
{
return;
}
this.Current++;
}
}

Now for the WPF window that will display this IProgressOperation. Since we will make the window implement INotifyPropertyChanged, when the ProgressChanged or ProgressTotalChanged events are raised from the background operation (and coming from a worker thread), we will just raise the events for WPF to update its bindings:

void _operation_ProgressChanged(object sender, EventArgs e)
{
OnPropertyChanged(”Current”);
}
void _operation_TotalChanged(object sender, EventArgs e)
{
OnPropertyChanged(”Total”);
}
public int Current
{
get
{
return this._operation.Current;
}
}
public int Total
{
get
{
return this._operation.Total;
}
}

Finally we have the XAML for the ProgressWindow that shows how it has both progress text and the Progressbar bound to the Current and Total properties that the window exposes to itself from the IProgressOperation.

<Grid>
<Grid.RowDefinitions>
<RowDefinition Height=”32″/>
<RowDefinition Height=”*”/>
<RowDefinition Height=”42″/>
</Grid.RowDefinitions>
<StackPanel Grid.Row=”0″ Orientation=”Horizontal” HorizontalAlignment=”Center” VerticalAlignment=”Bottom”>
<TextBlock FontSize=”16″>Processing: </TextBlock>
<TextBlock FontSize=”16″ Margin=”5,0,0,0″ Text=”{Binding Path=Current, ElementName=Window, Mode=OneWay}”/>
<TextBlock FontSize=”16″ Margin=”5,0,5,0″>of</TextBlock>
<TextBlock FontSize=”16″ Text=”{Binding Path=Total, ElementName=Window, Mode=OneWay}”/>
</StackPanel>
<ProgressBar Grid.Row=”1″
Width=”200″
Height=”20″
Value=”{Binding Path=Current, ElementName=Window, Mode=OneWay}”
Minimum=”0″
Maximum=”{Binding Path=Total, ElementName=Window, Mode=OneWay}”></ProgressBar>
<StackPanel Grid.Row=”2″ Orientation=”Horizontal” HorizontalAlignment=”Center”>
<Button Margin=”6,6,6,6″ Width=”80″ Height=”30″ Click=”CancelClick”>Cancel</Button>
</StackPanel>
</Grid>

How do we start the operation and display the ProgressWindow? It is just a matter of creating a new ProgressWindow and passing in the IProgressOperation into its constructor:

ProgressWindow progressWindow = new ProgressWindow(new EventLogExporter());
progressWindow.ShowDialog();

The ProgressWindow will call the Start() method on the IProgressOperation once the window has completely loaded.

Keep in mind that this ProgressWindow is a very simple example demonstrating the power of WPF and binding. It can easily be extended to display many other items such as status text or other information, all using binding and not having to worry about invoking on the UI thread. You can also use the concepts provided in this article to design your own more powerful and customized ProgressWindow.

Sample: SimpleWPFProgressWindow