BindingOperations.EnableCollectionSynchronization Method

.NET Framework (current version)

The .NET API Reference documentation has a new home. Visit the .NET API Browser on to see the new experience.

Enables a CollectionView object to participate in synchronized access to a collection that is used on multiple threads.

Namespace:   System.Windows.Data
Assembly:  PresentationFramework (in PresentationFramework.dll)

System_CAPS_pubmethodSystem_CAPS_staticEnableCollectionSynchronization(IEnumerable, Object)

Enables a CollectionViewobject to participate in synchronized access to a collection used on multiple threads by a simple locking mechanism.

System_CAPS_pubmethodSystem_CAPS_staticEnableCollectionSynchronization(IEnumerable, Object, CollectionSynchronizationCallback)

Enables a CollectionView object to participate in synchronized access to a collection used on multiple threads by using a mechanism other than a simple lock.

A WPF application can display a collection of data using an ItemsControl or one of its subclasses (ListBox, DataGrid, TreeView, ListView, etc.). WPF channels all its access to the collection through a subclass of CollectionView. Both the ItemsControl and the CollectionView have affinity to the thread on which the ItemsControl was created, meaning that using them on a different thread is forbidden and throws an exception. In effect, this restriction applies to the collection as well.

You may want to use the collection on multiple threads. For example, you want to update the collection (add or remove items) on a "data-gathering" thread, while displaying the results on a "user interface" thread, so that the UI remains responsive while data-gathering is happening. In such a situation, you are responsible for ensuring synchronized ("thread-safe") access to the collection. This is typically done using either a simple lock mechanism or a more elaborate synchronization mechanism such as semaphores, reset events, etc.

While you must synchronize your application's access to the collection, you must also guarantee that access from WPF (specifically from CollectionView) participates in the same synchronization mechanism.  You do this by calling the EnableCollectionSynchronization method.

To use a collection on multiple threads, one of which is the UI thread that owns the ItemsControl, an application has the following responsibilities:

  1. Choose a synchronization mechanism.

  2. Synchronize all access from the application to the collection using that mechanism.

  3. Call EnableCollectionSynchronization to inform WPF of the mechanism.

  4. Ensure that a change to the collection and the notification of that change (through CollectionChanged are atomic; no access from other threads can intervene.  (This is usually free. For instance, ObservableCollection<T> guarantees this, provided that all changes are protected by synchronization.)

  5. If you call DisableCollectionSynchronization, that call must also occur on the UI thread.

  6. If you want to use the same collection on multiple UI threads, you must call EnableCollectionSynchronization (and DisableCollectionSynchronization, if needed) separately on each UI thread.

  7. Avoid deadlock.  This is already the application's responsibility once it chooses to use synchronization, but it must also take into account WPF's participation in the synchronization. (See more, below.)

In return, WPF provides the following behavior:

  • The CollectionView accesses the collection using the given synchronization mechanism.

  • The CollectionView maintains a "shadow copy" of the collection for use on the UI thread.

  • CollectionChanged events are queued up as they arrive (on any thread).

  • Pending events are applied to the shadow copy asynchronously on the UI thread when it has the opportunity to do so.

  • The CollectionView will not directly use any other synchronization mechanism visible to the application. This is WPF's way of helping to avoid deadlock (see the previous item 7).

The net effect is that you can change the collection on any thread, and those changes eventually appear in the ItemsControl when the UI thread has time to "catch up".  The implementation has been tuned to throttle the rate that changes flow into the UI thread to keep background threads from saturating the UI thread and starving the response to normal user input.

Return to top