Click here to Skip to main content
15,867,330 members
Articles / Programming Languages / C#

Asynchronous Multi-threaded ObservableCollection

Rate me:
Please Sign up or sign in to vote.
4.85/5 (18 votes)
9 May 2014CPOL6 min read 123.9K   4.4K   112   40
An implementation of of a multi-threaded ObservableCollection.

Update 2014-04-18

  • Updated with .net Framework 4.5 (Now required)
  • Support some functionnalities to manage the collection as a recorder of changes (added/removed items): IsRecording, GetCopyOfRecordedItemsNew, GetCopyOfRecordedItemsRemoved
  • Support the new .net 4.5 interface: IReadOnlyList
  • Support usage of the collection as a stack with: Push and TryPop
  • Support usage of the collection as a queue with: Enqueue and TryDequeue (not optimized for queue but works)
  • Fixed some minors bugs

Update 2013-01-18 / Important note before usage...

My original implementation had some bugs that could happen in rare circumstances. But it could happen. In fact a real MT ObservableCollection (ObsCollMt) is impossible to my opinion due to this two interdependent points:

- To benefits of MT, you should not wait for any event handlers
- Not waiting for event handlers would compromise the expected behavior --> for example, a ui control implementation (grid) that would receive an event "ItemAdd" would expect the collection to be the same as it was before the event with and only the newly added item, which is not the case in MT.

Because of this. If hi performance is the target and you could live with two constraints : UI view of the obs coll could be readonly and duplicate of item is acceptable (I maintain a list and an observable collection at the ~ same time)... I would highly recommend the usage of: "CollectionMtWithAsyncObservableCollectionReadOnlyCopy" which I made it available here. Some explanation of the usage is available at the beginning of the class definition. I personnally use it at many places with no problem. I changed every usage of ObservableCollectionMt to CollectionMtWithAsyncObservableCollectionReadOnlyCopy. There is impacts but they are low. But don't forget to bind to the ObsColl property instead of binding directly to the instance.

The way CollectionMtWithAsyncObservableCollectionReadOnlyCopy works is modifying an internal list but synchronously add task to the queue of the dispatcher to duplicate the same action (add/remove) on the internal ObsColl. ObsColl will be updated whenever the dispatcher will reach the task. Both collection should be in sync when the dispatcher queue has processed every tasks (verified).

Introduction

ObservableCollections are mainly used in WPF to notify bound UI components of any changes. Those notifications usually translate to UI component updates, normally due to binding. UI component changes could only occur in a UI thread. Whenever you have lengthy work to do, you should do those jobs on a worker thread to improve the responsiveness of the UI. But sometimes, UI updates are very lengthy too. In order to decouple the worker thread from the UI thread, I created a collection which has in its internal 2 collections:

  • A list which could be accessed in a multithreaded context. Major properties/functions of a regular collection are supported. Major properties/functions are the same as a regular collection. Some functions that could potentially be thread unsafe are clearly indicated (start with 'Unsafe').
  • An ObservableCollection which should be used as read only from the UI. This collection is accessible through the ObsColl property. This ObsColl should be threaded as readonly otherwise it could lead to inconsitent data between both the list and the ObsColl.

Every modifications done to the ObsCollMt are done to the first internal list but are also queued to the dispatcher in the exact same order as they happen in the MT context (lock ensures this). The ObsColl should be an exact copy of the first internal list after UI would have processed all of its messages. But accessing the ObsCollMt would not suffer of waiting UI updates because of usage of Dispatcher.BeginInvoke.

Background

I found a few things but never exactly what I wanted. This is why I’m writing this article now. I took a look at: http://www.codeproject.com/KB/dotnet/MTObservableCollection.aspx (Paul Ortiz solution). And also http://powercollections.codeplex.com/. They weren’t what I expected. I also had some concerns about the first link (explained later).

Details

I decided to write my own multi-threaded ObservableCollection, but I got an unexpected major problem:

  • The major one was discovered after few attempts of making an ObservableCollection MT without dual copy of the data. I think, as explained at the beginning, to decouple UI from MT worker thread and keep data coherent, we should have dual list of the data, one for workers and one for UI. Also, the copy used for the UI should not be modify of if so, then is should be not used by any workers.

* An asynchronous update means, as a difference from the Paul Ortiz solution, that the worker thread does not have to wait on the UI to update before continuing to process other things. My solution uses Dispatcher.BeginInvoke instead of Disptacher.Invoke.

I also had a few other problems in testing when I realised that CollectionView had one major constraint and a bug. CollectionView does not support range modification. CollectionView also has a bug in it because it does not use a “using” block around an iterator to ensure that Dispose is called (or use a foreach loop which is fine too). (See: https://connect.microsoft.com/VisualStudio/feedback/details/513500/collectionview-does-not-dispose-sourcecollection-enumerator-synchronously for those who have access.)

This is a list of many problems I had with the actual implementation of the ObservableCollection:

  1. Function Clear does not notify
  2. Unable to override critical functions
  3. No multi-threaded safe access
  4. Needs possibility to get blocking and unblocking iterators
  5. Possibility to get either “blocking” or “list copy” iterator

Solution

I then decided to program my Swiss army knife collection. In fact, it is one collection for the multi-threaded, and a regular ObservableCollection. When accessing the ObsCollMt, you modify a regular list (with MT safe lock) and add notification to update the regular ObsColl in the UI thread.

The way I did it was a complete writing of the new class “ CollectionMtWithAsyncObservableReadOnlyCopy” not inheriting from Collection, with a “List<T>” member containing every item. The class supports most interface the standard ObservableCollection supports.

I have included a sample with threading access to show the main usage.

Do not forget to bind to "ObsColl" property instead of bind directly to the collection itself.

Hope you will like it.

History

  • April, 28, 2014, Made some corrections in text.
  • June, 03, 2013, Made a requested correction about verification of "Application.Current" not being null. Removed old source code which is a little bugged to remove confusion and to ensure to only use the new version with copy.
  • Mai, 31, 2013, Put code in a little lib, added a little test project, make project for VS2010 instead of VS 2012 (easier for more people to try)
  • Jan 18, 2013: Added information about "CollectionMtWithAsyncObservableCollectionReadOnlyCopy"
  • Apr 28, 2011: Updated source code. Updated the Introduction section.
  • Jun 23, 2011: Updated source code.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer IREQ - Hydro-Quebec
Canada Canada
Hi,

I'm a french Canadian software developer.
Work at Hydro-Quebec / IREQ.
Live in Sainte-Julie, Quebec, Canada (South shore of Montreal)

WebPage: http://www.ericouellet.com
GMail: ericouellet2

Salut!

Comments and Discussions

 
QuestionHow to download older version Pin
netizenk21-Aug-14 12:15
professionalnetizenk21-Aug-14 12:15 
AnswerRe: How to download older version Pin
Eric Ouellet25-Aug-14 9:26
professionalEric Ouellet25-Aug-14 9:26 
GeneralRe: How to download older version Pin
netizenk1-Sep-14 16:39
professionalnetizenk1-Sep-14 16:39 
GeneralRe: How to download older version Pin
Eric Ouellet2-Sep-14 8:34
professionalEric Ouellet2-Sep-14 8:34 
Questionthiet ke web ban hang Pin
Tú Vũ Anh9-May-14 18:52
Tú Vũ Anh9-May-14 18:52 
QuestionGreat Collection Pin
kiquenet.com5-May-14 0:27
professionalkiquenet.com5-May-14 0:27 
AnswerRe: Great Collection Pin
Eric Ouellet9-May-14 5:39
professionalEric Ouellet9-May-14 5:39 
QuestionWhat version of Visual Studio is required for the latest version? Pin
bscaer31-May-13 7:32
bscaer31-May-13 7:32 
AnswerRe: What version of Visual Studio is required for the latest version? Pin
Eric Ouellet31-May-13 8:42
professionalEric Ouellet31-May-13 8:42 
GeneralMy vote of 5 Pin
fredatcodeproject24-May-13 1:48
professionalfredatcodeproject24-May-13 1:48 
QuestionThe source for readonly addition is incomplete... Pin
roonius23-May-13 7:01
roonius23-May-13 7:01 
AnswerRe: The source for readonly addition is incomplete... Pin
Eric Ouellet23-May-13 7:54
professionalEric Ouellet23-May-13 7:54 
AnswerRe: The source for readonly addition is incomplete... Pin
Eric Ouellet28-Apr-14 5:14
professionalEric Ouellet28-Apr-14 5:14 
BugA bug in ObservableCollectionMt<T> class Pin
Jalal Khordadi9-Feb-13 7:53
Jalal Khordadi9-Feb-13 7:53 
Thanks for posting this perfect article Smile | :)
When app is running and filling the list, I hit close (x) button, suddenly a `NullReferenceException` occurred in RemoveAt fuction, because Application.Current was null. So you may want to check if it's null in other places of code.

in ObservableColletionMt.cs file, line 176:

C#
public virtual void RemoveAt(int index)
{
    // Here is NullReferenceException thrown because Application.Current is null when I close app immediately.
    if (Application.Current.Dispatcher.CheckAccess())
    {
        // rest of code...


I'm not sure if it's a good practice to check whether if Application.Current is null and just `return`, or it's programmer's responsibility to check it (using try catch) in Application End event.

C#
public virtual void RemoveAt(int index)
{
    // Check it for null to prevent NullReferenceException
    if (Application.Current == null)
        return;

    if (Application.Current.Dispatcher.CheckAccess())
    {
        // rest of code...


Best Regards
Jalal
The philosophers have only interpreted the world in various ways; The point however is to change it!
-Karl Marx-

GeneralRe: A bug in ObservableCollectionMt<T> class Pin
Eric Ouellet11-Feb-13 3:27
professionalEric Ouellet11-Feb-13 3:27 
GeneralRe: A bug in ObservableCollectionMt<T> class Pin
jogibear99881-Jun-13 13:51
jogibear99881-Jun-13 13:51 
GeneralRe: A bug in ObservableCollectionMt<T> class Pin
Eric Ouellet3-Jun-13 3:47
professionalEric Ouellet3-Jun-13 3:47 
GeneralRe: A bug in ObservableCollectionMt<T> class Pin
Eric Ouellet28-Apr-14 5:12
professionalEric Ouellet28-Apr-14 5:12 
GeneralMy vote of 5 Pin
Gunpal522-Dec-11 8:15
Gunpal522-Dec-11 8:15 
GeneralNice article! Pin
Wonde Tadesse10-Nov-11 15:26
professionalWonde Tadesse10-Nov-11 15:26 
GeneralRe: Nice article! Pin
Eric Ouellet14-Nov-11 4:02
professionalEric Ouellet14-Nov-11 4:02 
QuestionMy vote of 5 Pin
Filip D'haene23-Jun-11 9:58
Filip D'haene23-Jun-11 9:58 
AnswerRe: My vote of 5 Pin
Eric Ouellet23-Jun-11 10:06
professionalEric Ouellet23-Jun-11 10:06 
GeneralNice Pin
Member 456543329-Apr-11 3:33
Member 456543329-Apr-11 3:33 
GeneralRe: Nice Pin
Eric Ouellet29-Apr-11 4:42
professionalEric Ouellet29-Apr-11 4:42 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.