Click here to Skip to main content
Click here to Skip to main content
Go to top

Asynchronous Multi-threaded ObservableCollection

, 9 May 2014
Rate this:
Please Sign up or sign in to vote.
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)

Share

About the Author

Eric Ouellet
Software Developer
Canada Canada
Hi,
 
I'm a Canadian-french developer for many years now.
I'm actually programming in C# but I also had some fun in the past with: VB, C++, SQL, Java, etc.
I like to play games like Carcassone, Settlers of Catane, Chess, Poker...
I also like photography.
 
Salut!

Comments and Discussions

 
QuestionHow to download older version Pinmembernetizenk21-Aug-14 12:15 
AnswerRe: How to download older version PinmemberEric Ouellet25-Aug-14 9:26 
GeneralRe: How to download older version Pinmembernetizenk1-Sep-14 16:39 
GeneralRe: How to download older version PinmemberEric Ouellet2-Sep-14 8:34 
Questionthiet ke web ban hang PinmemberTú Vũ Anh9-May-14 18:52 
QuestionGreat Collection Pinmemberkiquenet.com5-May-14 0:27 
AnswerRe: Great Collection PinmemberEric Ouellet9-May-14 5:39 
QuestionWhat version of Visual Studio is required for the latest version? Pinmemberbscaer31-May-13 7:32 
AnswerRe: What version of Visual Studio is required for the latest version? PinmemberEric Ouellet31-May-13 8:42 
GeneralMy vote of 5 Pinmemberfredatcodeproject24-May-13 1:48 
QuestionThe source for readonly addition is incomplete... Pinmemberroonius23-May-13 7:01 
AnswerRe: The source for readonly addition is incomplete... PinmemberEric Ouellet23-May-13 7:54 
AnswerRe: The source for readonly addition is incomplete... PinmemberEric Ouellet28-Apr-14 5:14 
BugA bug in ObservableCollectionMt<T> class Pinmemberjalalx9-Feb-13 7:53 
GeneralRe: A bug in ObservableCollectionMt<T> class PinmemberEric Ouellet11-Feb-13 3:27 
GeneralRe: A bug in ObservableCollectionMt<T> class Pinmemberjogibear99881-Jun-13 13:51 
GeneralRe: A bug in ObservableCollectionMt<T> class PinmemberEric Ouellet3-Jun-13 3:47 
GeneralRe: A bug in ObservableCollectionMt<T> class PinmemberEric Ouellet28-Apr-14 5:12 
GeneralMy vote of 5 PinmemberGunpal522-Dec-11 8:15 
GeneralNice article! PinmemberWonde Tadesse10-Nov-11 15:26 
GeneralRe: Nice article! PinmemberEric Ouellet14-Nov-11 4:02 
QuestionMy vote of 5 PinmemberFilip D'haene23-Jun-11 9:58 
AnswerRe: My vote of 5 PinmemberEric Ouellet23-Jun-11 10:06 
GeneralNice PinmemberMember 456543329-Apr-11 3:33 
There are several other implementations, Sacha points his out
 
Have you seen this new release from Redmond ?
 
http://msdn.microsoft.com/en-us/vstudio/gg316360[^]
 
very nice
GeneralRe: Nice PinmemberEric Ouellet29-Apr-11 4:42 

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

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

| Advertise | Privacy | Mobile
Web01 | 2.8.140916.1 | Last Updated 9 May 2014
Article Copyright 2011 by Eric Ouellet
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid