Why is CollectionChanged not threadsafe?

Question

I'm working on a WPF application and found that property changed notifications on binded properties can happen from a background thread, however for making any change to an observablecollection(like adding or removing item) has to happen from a UI thread. My question is why is it so? Both INotifyPropertyChanged and INotifyCollectionChanged are subscribed by UI controls, then why an exception for INotifyPropertyChanged?

For example:

 public class ViewModel : INotifyPropertyChanged
    {
        ObservableCollection<Item> _items = new ObservableCollection<Item>();

        private string _name;
        public string Name
        {
            get { return _name; }
            set
            {
                _name = value;
                //Can fire this from a background thread without any crash and my 
                //Name gets updated in the UI
                InvokePropertyChanged(new PropertyChangedEventArgs("Name"));
            }
        }

        public void Add(Item item)
        {
            //Cant do this from a background thread and has to marshal.
            _items.Add(item);
        }

        public event PropertyChangedEventHandler PropertyChanged;

        public void InvokePropertyChanged(PropertyChangedEventArgs e)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null) handler(this, e);
        }
    }

NOTE: CollectionChanged event from a background thread crashes the app, however PropertyChanged event from a background thread updates the UI without any issues and yes, this is in .NET 4.0

ObservableCollection is not a thread-safe class, few collection classes are. There's no requirement whatsoever that changes need to be made on the UI thread. However, if you listen to the PropertyChanged event in a class that tinkers with the UI then it certainly does start to matter. This doesn't have anything to do with the collection class, everything to do with what your event handler code does. — Hans Passant, Oct 04 '13 at 14:39
@Hans:Exactly, both notify property changed and notify collection changed is subscribed by UI controls (like a grid). Why does it allow to raise property changed notifications on scalar properties from a background thread(with no need of marshalling), but NotifyCollectionChanged only from a UI thread? — Mike, Oct 04 '13 at 14:44

score 5 · Answer 1 · edited May 23 '17 at 10:25

5

This problem is not related to thread safety. The issue is that the CollectionChanged event is raised from a worker thread, which means the handlers are executed in that same thread, and when a handler tries to touch the UI you have an exception because that's only allowed from the UI thread.

The same would also happen for the PropertyChanged event if the situation were identical, there is no special treatment being given to either event.

If you need to touch the UI from within your event handlers then you have to either make sure the event is raised on the UI thread or else the event handlers have to check with Dispatcher.CheckAccess if marshalling changes to the UI thread is needed and Dispatcher.BeginInvoke to do so.

edited May 23 '17 at 10:25

Community

1
1

answered Oct 04 '13 at 14:43

Jon

428,835
81
738
806

Well raising Collection Changed from background thread crashes the app, however PropertyChanged does not. When I raise PropertyChanged event, I would imagine the handler is still getting executed in the same thread context (or does framework does that for you(?), if yes why not for collection changed?) – Mike Oct 04 '13 at 14:47
@Mike: It totally depends on what the event handlers do. They are always executed on the thread that raises the event unless there is something explicit going on that does otherwise, which in this case there is not. – Jon Oct 04 '13 at 14:49
Is it _your_ handler being executed for the event? If so, most likely your event handling isn't accounting for the fact that the event might not be on the expected thread. – Basic Oct 04 '13 at 14:49
PropertyChanged event from a background thread updates the UI without any issues. – Mike Oct 04 '13 at 14:50
@Mike: What does "updates the UI" mean? If the binding pipeline does the updating then there will be no issues because it explicitly marshals the modifications to the UI thread. But try to do that from inside your own handler, e.g. `PropertyChanged += (o, s) => { control.Text = "foo"; }` and you will crash. – Jon Oct 04 '13 at 14:54
1

UpdateUI-Updates are shown on the UI without any crash. The original question is why does the binding pipeline do that for scalar properties and not for collections? – Mike Oct 04 '13 at 14:57
1

@Mike: I 'm not sure if anyone could answer that question outside the WPF team. To hazard a guess, property-triggered changes are "simple" operations: after all is said and done, the pipeline has a value that it wants to push to the control and acting on that is going to be safe regardless of what's going on on the worker thread. While if a collection is changed then we are facing much more work (creating new windows, determining binding values for them, etc etc), and starting to act on that would invite race conditions if the worker thread is still modifying stuff. – Jon Oct 04 '13 at 15:03
@Mike: In turn, that could be prevented by the pipeline using `Invoke` instead of `BeginInvoke` but this could easily result in "WTF is my worker thread blocking??!?!!1" and/or deadlocks. So, no solution that is good across the board => everybody fend for themselves on their own. – Jon Oct 04 '13 at 15:05

EldHasp · Answer 2 · 2021-09-17T10:29:52.177

Most likely you mean the binding mechanisms.

Binding does not work directly with the CLR property and the PropertyChanged event.
Binding uses reflection for its work. These are in order of priority: PropertyDescriptor, PropertyInfo, DependencyProperty, and DynamicPropertyAccessor.
You can see it here: PropertyPathWorker.SetValue(object item, object value).
For the same reason, if a property changes ONLY by bindings, then it will be monitored regardless of the presence of the INotifyPropertyChanged interface.
Also, the use of reflection allows you not to worry in which flow the observed property will be changed.

In the case of collections, binding is also insensitive to the stream in which this collection will be assigned to the monitored property.
BUT monitoring of changes in the collection (INotifyCollectionChanged and IBindingList) is no longer provided by the binding mechanism, but by the internal logic of the ItemsControl class.
There is already a direct subscription to observation events, this makes this logic sensitive to the thread in which the collection will change. If it is not a UI thread, then the observation will be destroyed, or even an exception will be thrown.

It is enough just to be convinced of this.

Demo example. Class ViewModel with random collection change.

public class RandomCollectionViewModel
{
    public ObservableCollection<int> Numbers { get; }
        = new ObservableCollection<int>() { 1, 2, 3 };
    private static readonly Random random = new Random();
    private readonly Timer timer = new Timer();

    public RandomCollectionViewModel()
    {
        timer.Interval = 500;
        timer.Elapsed += (s, e)
            => Numbers[random.Next(Numbers.Count)] = random.Next();
        timer.Start();
    }
}

XAML using bindings to display collection items:

<StackPanel>
    <FrameworkElement.DataContext>
        <local:RandomCollectionViewModel/>
    </FrameworkElement.DataContext>
    <TextBlock Text="{Binding Numbers[0]}"/>
    <TextBlock Text="{Binding Numbers[1]}"/>
    <TextBlock Text="{Binding Numbers[2]}"/>
</StackPanel>

XAML using ItemsControl to display collection items:

<StackPanel>
    <FrameworkElement.DataContext>
        <local:RandomCollectionViewModel/>
    </FrameworkElement.DataContext>
    <ItemsControl ItemsSource="{Binding Numbers}"/>
</StackPanel>

These examples clearly show the difference in the work of bindings and ItemsContol.

Why is CollectionChanged not threadsafe?

2 Answers2

Linked