In this section look into multithreading in WPF and how we can send long running task to a different thread than the UI thread. We will look at how the threading model of WPF works. We will also look into how we can load data in a different long running thread and then utilize that data through data binding. Also we will see how we can communicate with WCF from WPF.

WPF Threading Model

Responsive UI and Distributed Systems

In our application if we are dealing with data which is coming from remote system then we cannot deny the fact there can be network delays because of various reasons (Network congestion, Busy Servers, Packet Loss, higher round trip times, etc) and that could render our UI unresponsive. Other reasons for UI unresponsiveness could be long running IO tasks or slow CPU. So we should take care of this while designing the application and make sure the UI does not freeze in such conditions.

Dispatcher

The WPF threading model revolves around an object called as dispatcher. It can be considered as the object that owns the message loop for a particular thread. In any windows application all the mouse and keyboard inputs are sent via message sent to the thread associated with the target window. In WPF receives these messages and decides what to do with them. All WPF elements are associated with the Dispatcher. We can see this in the DispatcherObject base class. This is the base of DependencyObject which is root of WPF class hierarchy.

WPF Dispatcher

As we have seen that DependencyObject object is the base class for most WPF types and it in turn derives from DispatcherObject which derives from System.Object, the base class for all .NET objects. The DispatcherObject provides access to the object to which the Dispatcher is associated and it provides functions to check whether we are on the right thread or not. The Dispatcher is always associated with a particular thread and in most cases we need to be on that thread when we make any changes to the object on that thread. WPF makes use of these methods to make sure we are performing operations on the right thread.

• CheckAccess – This will return false if we are on the wrong thread.
• VerifyAccess – This will throw an exception if we are on the wrong thread.

So this is in accordance with STA model. The reason why WPF uses this model is to work with COM based API’s like clipboard, etc.

However it is technically possible for an application to have multiple dispatchers each on a different thread but each top level window needs to be on a single dispatcher. However its very common to have only one dispatcher for one WPF application. And also generally a WPF application has one UI thread but that’s not a constraint. So we cannot modify anything on the UI elements from the wrong thread means non UI thread directly. As all the user inputs are handled by the dispatcher so when we do any other task on that thread then the dispatcher will not be to handle the user input. So we should not block the UI thread to the functions that take long time to complete.

So how do we follow both the things I just said above because one says do all the work on UI thread to avoid exceptions and the second one says do no work on UI so that the UI is responsive.

Async Work

The answer is to perform slow work asynchronously either by using multithreading or some API’s. If we want to update the UI in between these tasks then we can use the Dispatcher to come back on the right thread for updating the UI. We can do this by calling the Dispatcher.BeginInvoke method and passing the method delegate to it. This will end up as a message in the message queue of the dispatcher and when the dispatcher processes this message in its queue it will invoke the specified method and make eth updates to the UI thread. This will make sure that the UI updates will happen always on the right thread no matter what thread we are on.

We can see how to do this in the image below. We have some slow work to do. As you can see this work has been put in an anonymous delegate and this is invoked by a thread in a thread pool. So we have delegated the slow work to some other thread so that the UI is responsive and when the slow work is completed and the UI needs to be updated then we have called Dispather.BeginInvoke to our UI update.

ThreadStart threadStart = somedelegate // We can use any type of delegate

{

DoSomeLongRunningWork();

Dispatcher.BeginInvoke(DispatcherPriority.Normal, (EventHandler) delegate

{

UpdateTheUI();

}, null, null);

};

threadStart.BeginInvoke(delegate(IAsyncResult asyncRes) { threadStart.EndInvoke(asyncRes); }, null);

Let’s see this action. Add a class in with the following code in your application to do the time consuming task.

WPF Async Work

Now add the following code to the xaml of the application.

WPF Async Work

Add the following code to the code behind.

WPF Async Work

When we run this code we will notice that during the time our time consuming task runs the ui is responsive and if we have a look at the Thread ids we will notice that we ran the Time consuming task on a different thread then the other tasks and in the end we used Dispatcher object to Update the UI.

WPF Async Work

Dispatcher Priorities

As we have seen the previous section that we specified DispatcherPriority.Normal in the Dispathcer.BeginInvoke method. The different dispatcher priorities are as below and these are increasing order of priority. For example the DataBinding has higher priority than rendering. This is how it should be. Say we have an application that databinds all the elements on a page and suppose the data binding for all the elements is updated then we do not want call render for each element separately. So we just get one painting of the UI.

• System Idle
• Application Idle
• Context Idle
• Background
• Input
• Loaded
• Render
• DataBind
• Normal
• Send

DispatcherOperation

This is returned by Dispatcher.BeginInvoke and can be used to track the progress of the work.

• Status Property – It has the status property which tells us whether the operation is still pending in the queue or executing or finished or aborted.
• Result Property – It also has a result property that can be used to get the outcome of the operation if there was any.
• Priority Property – The objects also provide access to the operations priority as well.
• Completed Event – Called when the operation completes.
• Aborted Event – Called when the operation aborts.
• Wait Operation – This method block until the operation completes and if the operation has already completed before we have called wait then wait returns immediately. You need to be cautious while using Wait because you are blocking the worker thread till the UI operation is completed and this might lead to a deadlock as the UI thread might be waiting for the Worker thread to finish up.
• Abort Operation – This operation aborts the operation if the operation is still waiting in the queue. If the operation has already started or finished the Abort does nothing.

Synchronization Context

Instead of using the Dispatcher.BeginInvoke we can use the SynchronizationContext.Post method to make the updates to the UI. This was introduced in the version 2.0 of .NET and also works for Windows Forms and ASP.NET. A dummy implementation for this is shown in below.

SynchronizationContext synchronizationContext = SynchronizationContext.Current;

ThreadStart threadStart = delegate 
{
    DoLongRunningWork(); 
    synchronizationContext.Post(delegate 
    {
        UpdateUI();
    }, null);
}; 
threadStart.BeginInvoke(delegate(IAsyncResult asyncResult)
{ 
    threadStart.EndInvoke(asyncResult);
}, null);

Asynchronous Options

Let’s have a look at the various asynchronous options available with .NET.

.NET v 1 asynchronous pattern

Whenever we see two methods, one called Begin___ and the other called End___ we know that we are using .NET v1 Async pattern. The Begin___ method needs to return result of type IAsyncResult and should also allow you pass a Callback function that will notify the completion of the method. The types that support this pattern are as below:

• All delegates support this pattern
• All networking classes implement it
• All web service proxy classes implement this including WCF

The major advantage of using this pattern is that we gain a lot on the efficiency of the pattern. Just like the concurrent threads work in the Windows Operating system, the same the way this implementation needs the CPU time at the start and end of the operation explicitly and the remaining work is done concurrently. Like if it’s an IO task then it’s handled asynchronously by specialized hardware. So the major advantage of this pattern is its efficiency and we manage thousands of network operations with a few threads.

But this might not be very useful for a WPF application as the main use of threading in a WPF application if just maintain the responsiveness of the UI.

.NET v2.0 event-based asynchronous pattern

This pattern was introduced with .NET 2.0 and is more suited for user interface development.

In this pattern we will find methods of type ___Async and CancelAsync or ___AsyncCancel. So this pattern supports cancellation in scenarios where it can be done.

Another feature that we see in this pattern is that an event will fire when the operation completes and also when the progress of the task is changed.

And the most important thing to notice is that these events are raised on the user interface threads. This is a mandatory requirement for the components implementing this pattern. This is generally done by SyncronizationContext or AsyncOperationManager to make sure the events are raised on the thread on which the operation was invoked.

The advantages of this pattern are that it offers cancellation and is simple to use. The major advantage of this pattern is that presents a Single threaded API for multithreaded operations. So when are using a component that implements this pattern we don’t see anything other than the dispatcher thread for Async operations. So we call the Async work from the UI thread and we get the completed notifications back on the UI thread.

We have seen an example of this implementation in the Printing section. The XPSDocumentWriter offers the WriteAsync and CancelAsync methods.

So this method seems perfect for WPF but the couple of cons for this pattern are that it is not widely supported and it does not support the WaitHandle available in the V1 Pattern.

Thread Pool

Some components offer nothing but a synchronous blocking API. We saw this in the section where I showed you the TimeConsumingTask. So we need to go and manage the blocking and unblocking of the thread.

We could use a Thread Pool for it. .NET always provides pool of thread to do random work on random threads. .NET dynamically creates and destroys thread to meets the applications workload and this is really helpful in synchronizing the unhelpful synchronous components. You should remember that anytime we are using a delegate asynchronously we are using the thread pool internally.

The V1 and V2 of .NET asynchronous also use the thread pool in some implementations like the background worker class.

The only problem in working with thread pool is to get back to the UI thread when the work is done.

Create your own thread

Finally the last option is create our own worker thread. The major advantage of creating your thread is to have less concurrency. Yes it’s an advantage in terms of WPF because the only reason for asynchronous work is to ensure the responsiveness of the WPF UI.

The best way to go for a WPF application is to have one worker thread and one UI thread. And having only 2 threads will simplify the concurrency issues as we know what work is being done on what thread.

The only disadvantage with this is that there is no direct support for this approach in .NET library so we have built up our own mechanism to pass the messages between the worker thread and the UI thread. It’s not a lot of work as we just need a queue and some synchronization. But we should not be hesitant for the approach a little work upfront will give a lot of flexibility.

Databinding and Threading

In the previous sections we have seen how we can update the UI coming back from the worker thread. Now we will see how we can update the UI if we are using data binding. This is useful in the cases our data source is producing the change notifications. Add the following class and code to you application. This class will provide datasource which provides slow data. As we can see in the code the get accessor is fast but the set accessor is fetching the updates. The FetchNewData method simulates the slow operation. We are using the thread pool to get the work done and then we are sleeping on the thread for 5 seconds and then the property is updated. Also you can see that this class implements the INotifyPropertyChange to implement the change notifications.

WPF Databinding and Threading

This is used as the source for the UI as we can see in the code below. This source becomes the DataContext of the Window.

WPF Databinding and Threading

And we go to the xaml we will see that the textblock’s text property is bound to the data property of the DataContext.

WPF Databinding and Threading

WPF will take care of this as you can see by running the application.

WPF Databinding and Threading

However this is supported only in case of properties for the current version of WPF. If we are using a list and using data binding on the list with multithreading then we will get an error. So WPF actually offers only partial support for Async updates. Maybe the future versions might offer it as currently WPF does not offer a CollectionView that support changes to its collection from a thread different from a dispatcher thread.

We can change our approach to get this done. For example we can create our ObjectDataProvider (ObjectDataProvider.IsAsychronous) on the worker thread instead of the UI thread. And we can also set the binding on a particular element to be Async (Binding.IsAync).

I do not recommend this approach because xaml is not the place to handle the threading issues. So we are usually better off handling these issues in the DataSource.

WCF and WPF

WCF and v1 Async Pattern

If we are using WCF along with WPF then we can use the Async proxy class generated by WCF to perform work asynchronously. This can be done in two ways

• While generating the Async class via command line we can affix /async at the last of the svcutil.exe command
• Or in Visual studio while adding the service reference we can configure it work Async.

This setting will make the generated proxy to implement the .NET v1 Async pattern. This does not require any implementation form the server as this is just the way we want WCF to present the proxy.

svcutil.exe http://services.msdn.microsoft.com/ContentServices/ContentService.asmx?wsdl /language,C# /async
 
[ServiceContract(Namespace="urn:msdn-com,public-content-syndication", ConfigurationName="ContentServicePortType")]
public interface ContentServicePortType { 
[OperationContract(AsyncPattern=true, Action."urnmsdn-com:public-content-syndication/GetContent", ReplyAction."*")]
IAsyncResult BeginGetContent(GetContentRequest request, AsyncCallback callback, object asyncState); 

GetContentResponseEndGetContent(IAsyncResult asyncResult);

WCF and DataBinding

WCF also offers some help for the databinding as well. The svcutil has the option which will implement the INotifyPropertyChange on the types generated form the schema.

This is useful when the WPF application using a simple visual layout only directly over WCF service.

Any questions, comments or feedback are most important.

The code for this post can be found here.