views:

1030

answers:

9

I need to enumerate though generic IList<> of objects. The contents of the list may change, as in being added or removed by other threads, and this will kill my enumeration with a "Collection was modified; enumeration operation may not execute."

What is a good way of doing threadsafe foreach on a IList<>? prefferably without cloning the entire list. It is not possible to clone the actual objects referenced by the list.

+1  A: 

Forech depends on the fact that the collection will not change. If you want to iterate over a collection that can change, use the normal for construct and be prepared to nondeterministic behavior. Locking might be a better idea, depending on what you're doing.

Patrick
@Patrick: It would be nice if .net defined some collections with nice semantics if they were changed during enumeration (e.g. every item that exists through the life of an enumeration will be returned exactly once, and items that exist during part of an enumeration will be arbitrarily returned zero or one times). Unfortunately, I'm unaware of any. Normal behavior of nearly all the collection types is to throw an exception if the collection is edited; one useful exception is the VB6-style "Collection" class; unfortunately, that's pretty limited in other ways.
supercat
+1  A: 

There is no such operation. The best you can do is


lock(collection){
    foreach (object o in collection){
       ...
    }
}
Jason Punyon
+8  A: 

Cloning the list is the easiest and best way, because it ensures your list won't change out from under you. If the list is simply too large to clone, consider putting a lock around it that must be taken before reading/writing to it.

John Millikin
A: 

Wrap the list in a locking object for reading and writing. You can even iterate with multiple readers at once if you have a suitable lock, that allows multiple concurrent readers but also a single writer (when there are no readers).

jamuraa
+2  A: 

Your problem is that an enumeration does not allow the IList to change. This means you have to avoid this while going through the list.

A few possibilities come to mind:

  • Clone the list. Now each enumerator has its own copy to work on.
  • Serialize the access to the list. Use a lock to make sure no other thread can modify it while it is being enumerated.

Alternatively, you could write your own implementation of IList and IEnumerator that allows the kind of parallel access you need. However, I'm afraid this won't be simple.

jan.vdbergh
A: 
ICollection MyCollection;
// Instantiate and populate the collection
lock(MyCollection.SyncRoot) {
  // Some operation on the collection, which is now thread safe.
}

From MSDN

Forgotten Semicolon
+2  A: 

You'll find that's a very interesting topic.

The best approach relies on the ReadWriteResourceLock which use to have big performance issues due to the so called Convoy Problem.

The best article I've found treating the subject is this one by Jeffrey Richter which exposes its own method for a high performance solution.

Jorge Córdoba
+1  A: 

So the requirements are: you need to enumerate through an IList<> without making a copy while simultaniously adding and removing elements.

Could you clarify a few things? Are insertions and deletions happening only at the beginning or end of the list? If modifications can occur at any point in the list, how should the enumeration behave when elements are removed or added near or on the location of the enumeration's current element?

This is certainly doable by creating a custom IEnumerable object with perhaps an integer index, but only if you can control all access to your IList<> object (for locking and maintaining the state of your enumeration). But multithreaded programming is a tricky business under the best of circumstances, and this is a complex probablem.

Jeffrey L Whitledge
+1  A: 

Default behavior for a simple indexed data structure like a linked list, b-tree, or hash table is to enumerate in order from the first to the last. It would not cause a problem to insert an element in the data structure after the iterator had already past that point or to insert one that the iterator would enumerate once it had arrived, and such an event could be detected by the application and handled if the application required it. To detect a change in the collection and throw an error during enumeration I could only imagine was someone's (bad) idea of doing what they thought the programmer would want. Indeed, Microsoft has fixed their collections to work correctly. They have called their shiny new unbroken collections ConcurrentCollections (System.Collections.Concurrent) in .NET 4.0.

You're verging on being offensive here. Perhaps you could edit your answer to be a little less unpleasant.
John Saunders