Is it safe to bind WPF controls to data updated in Timer?

Question

I have a WPF application that is updating its data model within a timer which updates its data at 1 Hz. As I understand it, a Timer works on a separate thread from the GUI. Everything seems to work great, but I'm reading around and see conflicting reports on whether it's ok to update data on a thread different from the GUI thread. We are running with .NET framework 4 Client Profile. The below article says things are fixed in 4.5 but it still isn't clear to me that it is. Can someone clarify this for me? We aren't using collections in our binding as of yet. Is that why we're not having trouble.

WPF Databinding thread safety?

Answer 1

yeah. It is thread safe. INotifyPropertyChanged is always marshalized to UI thread from other threads.

There is no need to dispatch PropertyChanged from another thread to UI thread, as the PropertyChanged event is automatically marshalled to the UI dispatcher.

As a MSDN article says:

Note that in WPF, things are different and the code shown in Figure 5 works even if the Status property is data-bound to a TextBlock. This is because WPF automatically dispatches the PropertyChanged event to the main thread, unlike all the other XAML frameworks. In all other frameworks, a dispatching solution is needed.

However, it is only true for change notifications on scalar properties (i.e. PropertyChanged event). Collection change notifications (INotifyCollectionChanged.CollectionChanged event) don't work that way, they must be raised on the UI thread manually. That is, when using INotifyCollectionChanged (such as with an ObservableCollection), these changes are not marshaled to the UI thread. This means that if you modify collection from non UI thread, you’ll take an exception. For example, there is some ViewModel We’re in the ViewModel class and we don’t use the Dispatcher to update UI. So I advise to you to use David Rickard's approach:

public static class DispatchService
{
    public static void Invoke(Action action)
    {
        Dispatcher dispatchObject = Application.Current.Dispatcher;
        if (dispatchObject == null || dispatchObject.CheckAccess())
    {
            action();
        }
        else
        {
            dispatchObject.Invoke(action);
        }
    }
}

and:

DispatchService.Invoke(() =>
{
    this.MyCollection.Add("new value");
});

David Rickard article at msdn blog.

Update:

yeah, the article uses MVVMLight framework. However, it is not correct that MVVM Light uses Dispatcher to marshal scalar property to UI thread. It can be seen from source code of ViewModelBase class from MVVM Light that there is no marshal between threads to update scalar property. Please, see RaisePropertuChanged() method.

In order to dispel any doubts on dispatching scalar properties I've made a test:

XAML:

<TextBlock Text="{Binding Number}" FontSize="188" Foreground="Red" />

ViewModel:

public int Number { get; set; }

private void UpdateNumber()
{
        Task.Run(() => 
        {
            System.Timers.Timer timer = new System.Timers.Timer(250);
            timer.Elapsed += (sender, eventArgs) =>
            { 
                Number++;
                OnPropertyChanged("Number");//No exceptions, no errors
            };
            timer.Enabled = true;
        });
}

Update 1:

There is no doubt that INotifyProperyChanged event is automatically dispatched by WPF to UI Thread. I believe a MSDN article and the link you've shown in your question:).

Pay attention to this: This is because WPF automatically dispatches the PropertyChanged event to the main thread, unlike all the other XAML frameworks.

Answer 2

No, it is not thread safe. A common way to fix that is by switching to the UI thread in the raiser of the notify property changed event.

Updating the view or viewmodel 1000 times per second is, in general, useless because the display is only updated 60 times per second or so and the average user is not able to read a thousand values per second in text.

The same code that raises the notification event could throttle the number of times the event gets raised per second.