Question: Platform: `WPF, .NET 4.0, C# 4.0`

Problem: In the Mainwindow.xaml i have a ListBox bound to a Customer collection which is currently an ObservableCollection< Customer >.

`ObservableCollection<Customer> c = new ObservableCollection<Customer>();`

This collection can be updated via multiple sources, like FileSystem, WebService etc.

To allow parallel loading of Customers I have created a helper class 

`public class CustomerManager(ref ObsevableCollection<Customer> cust)`

that internally spawns a new Task (from Parallel extensions library) for each customer Source and adds a new Customer instance to the customer collection object (passed by ref to its ctor).

The problem is that ObservableCollection< T> (or any collection for that matter) cannot be used from calls other than the UI thread and an exception is encountered:

"NotSupportedException – This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread."

I tried using the 

`System.Collections.Concurrent.ConcurrentBag<Customer>` 

collection but it doesnot implement INotifyCollectionChanged interface. Hence my WPF UI won't get updated automatically.

**So, is there a collection class that implements both property/collection change notifications and also allows calls from other non-UI threads?**

By my initial bing/googling, there is none provided out of the box.

Edit: I created my own collection that inherits from *ConcurrentBag< Customer >* and also implements the *INotifyCollectionChanged* interface. But to my surprise even after invoking it in separate tasks, the WPF UI hangs until the task is completed. **Aren't the tasks supposed to be executed in parallel and not block the UI thread**?

Thanks for any suggestions, in advance.

Answer: 
I spent ages looking at all the solutions and none really fit what I needed, until I finally realized the problem: I didn't want a threadsafe list - I just wanted a non-threadsafe list that could be modified on any thread, but that notified changes on the UI thread.

(The reason for not wanting a threadsafe collection is the usual one - often you need to perform multiple operations, like "if it's not in the list, then add it" which threadsafe lists don't actually help with, so you want to control the locking yourself).

The solution turned out to be quite simple in concept and has worked well for me. Just create a new list class that implements `IList<T>` and `INotifyCollectionChanged`. Delegate all calls you need to an underlying implementation (e.g. a `List<T>`) and then call notifications on the UI thread where needed.

```
public class AlbumList : IList<Album>, INotifyCollectionChanged
{
    private readonly IList<Album> _listImplementation = new List<Album>();

    public event NotifyCollectionChangedEventHandler CollectionChanged;

    private void OnChanged(NotifyCollectionChangedEventArgs e)
    {
        Application.Current?.Dispatcher.Invoke(DispatcherPriority.Render, 
                     new Action(() => CollectionChanged?.Invoke(this, e)));
    }

    public void Add(Album item)
    {
        _listImplementation.Add(item);
        OnChanged(new NotifyCollectionChangedEventArgs(
                      NotifyCollectionChangedAction.Add, item));
    }

    public bool Remove(Album item)
    {
        int index = _listImplementation.IndexOf(item);
        var removed = index >= 0;
        if (removed)
        {
            _listImplementation.RemoveAt(index);
            OnChanged(new NotifyCollectionChangedEventArgs(
                          NotifyCollectionChangedAction.Remove, item, index));
        }
        return removed;
    }
    // ...snip...
}

```
There's a detailed explanation and an implementation [here](http://lambert.geek.nz/2007/10/30/wpf-multithreaded-collections/). It was written mainly for .NET 3.5 SP1 but it will still work in 4.0.

The primary target of this implementation is when the "real" list exists longer than the bindable view of it (eg. if it is bound in a window that the user can open and close). If the lifetimes are the other way around (eg. you're updating the list from a background worker that runs only when the window is open), then there are some simpler designs available.