Background
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)
- Events from this worker class are raised on the UI thread
- A SynchronizationContext is used rather than Control.Invoke or Dispatcher.Invoke
- The UI code does not have to worry about what thread is executing, it always assumes the UI thread (keeps code clean)
- 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.
July 22nd, 2008 
Uncategorized
