wpf - How to deal with cross-thread access exceptions?

Question

A common exception one can get when working with multiple threads in WPF is:

The calling thread cannot access this object because a different thread owns it

What are the options to deal with this properly?

Answer 1

Depending on the situation there are various options:

Accessing a control from another thread

^{e.g. updating a TextBlock with progress information.}

• Data Binding:

  In this case the easiest thing you can do is avoiding the direct interaction with the control. You can just bind the property you want to access or modify to an object whose class implements INotifyPropertyChanged and then set the property on that object instead. The framework will handle the rest for you. (In general you rarely should need to interact with UI-elements directly, you can almost always bind the respective properties and work with the binding source instead; one case where direct control access may be necessary is control authoring.)

  There are some cases where data binding alone is not enough, for example when trying to modify a bound ObservableCollection<T>, for this you need...

• Dispatching:

  You can dispatch your accessing code to the thread owning the object, this can be done by calling Invoke or BeginInvoke on the Dispatcher owning the object being accessed (getting this Dispatcher is possible on another thread).

  e.g.

  new Thread(ThisThreadStart).Start();
  

  void ThisThreadStart()
  {
      textBlock.Dispatcher.Invoke(new Action(() => textBlock.Text = "Test"));
  }
  

  If it is not clear on which thread a method is executed you can use Dispatcher.CheckAccess to either dispatch or execute an action directly.

  e.g.

  void Update()
  {
      Action action = () => myTextBlock.Text = "Test";
      var dispatcher = myTextBlock.Dispatcher;
      if (dispatcher.CheckAccess())
          action();
      else
          dispatcher.Invoke(action);
  }
  

  If an object is not a DispatcherObject and you still need the associated Dispatcher you can use Dispatcher.CurrentDispatcher in the thread creating the object (so doing this in the method being executed by a thread will not do you any good). For convenience as you usually create objects on the application's main UI thread; you can get that thread's Dispatcher from anywhere using Application.Current.Dispatcher.

Special cases:

• BackgroundWorker

  Move any control access to ProgressChanged as it occurs on the thread that created the instance (which should of course be the UI-thread)

• Timers

  In WPF you can use the DispatcherTimer for convenience, it does the dispatching for you so any code in Tick is invoked on the associated dispatcher. If you can delegate the dispatching to the data binding system you of course can use a normal timer as well.

You can read more about how the Dispatcher queue works and WPF threading in general on MSDN.

Accessing an object created on another thread

^{e.g. loading an image in the background.}

If the object in question is not Freezable you should in general simply avoid creating it on another thread or restricting access to the creating thread. If it is Freezable you just need to call Freeze to make it accessible to other threads.

Accessing a data object from another thread

That is, the type whose instance is being updated is user-code. If an exception is thrown this situation probably came about by someone using DependencyObject as base type for a data class.

This situation is the same as accessing a control and the same approaches can be applied but usually it should be avoided in the first place. Granted, this allows for simple property change notifications via dependency properties and those properties can also be bound but often enough this is just not worth giving up thread-independency. You can get change notifications from INotifyPropertyChanged and the binding system in WPF is inherently asymmetrical, there always is a property that is bound (target) and something that is the source for this binding. Usually the UI is the target and the data is the source, meaning that only UI components should need dependency properties.