4

Is there a wrapper that completely removes this error? I have multiple loops on multiple threads and it is impossible for me to predict whether a collection is going to get modified in the middle of the foreach, I imagine it could be easily achievable by catching this specific error and getting a new handler for the collection and looping through the remaining elements however I am not advanced enough to override the default behavior with such a function.

user2534406
  • 65
  • 1
  • 7

1 Answers1

8

Assuming you're using .NET 4, you could use one of the collections in System.Collections.Concurrent, such as ConcurrentBag. However, you haven't really specified any requirements, so it's hard to know whether ConcurrentBag itself would meet them.

If you read the thread safety documentation for most collections, you'll find that they don't support safe modification from one thread while the collection is being read (or modified) by another, without locking. It's fine to read from a List<T> etc from multiple threads if it's not being modified by anything, but you shouldn't have even a single thread modifying it.

Ideally, try to design your code so that you don't require this unfettered write access to shared collections - but if you really need it, use a type which was designed for it.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • @user2534406: You could use a ConcurrentDictionary for the set, and just ignore the value. There's no equivalent for array... although the failure modes are different anyway due to the fixed size. (This is the problem - you've given us no actual requirements...) – Jon Skeet Jun 30 '13 at 15:29
  • @user2534406, I think you can try Lock mechanism, but in that case, you have to consider that any thread that tried to modified your array (in locked mode), should wait for its turn.. you can check http://stackoverflow.com/questions/59590/lock-keyword-in-c-sharp or http://stackoverflow.com/questions/6029804/how-does-lock-work-exactly-c-sharp links to check how it works and when to use. I faced a similar problem and lock saved me some time. – Mehbube Arman Jun 30 '13 at 15:34
  • Using lock is not an option. – user2534406 Jun 30 '13 at 15:40
  • @user2534406: Well I'm afraid I've given you all the help I can, I suspect the same is true for everyone else, given the lack of information you're giving in the question and comments. We don't know what you're trying to achieve, or what you're able to use. Hopefully my answer helps, but if not I'm afraid you'll *have* to give more information. – Jon Skeet Jun 30 '13 at 15:42
  • I have given a very specific description what other info do you need? I just want to get a handler for the newest collection if the modified collection exception is thrown – user2534406 Jun 30 '13 at 15:54
  • @user2534406: No, you really haven't given a very specific description. You haven't told us anything about the properties of the collection you need, other than it being thread-safe. Does it need to preserve order? Allow for duplicates? Be accessible by index? Allow for replacementment? I thought you were trying to *avoid* the exception being thrown in the first place... – Jon Skeet Jun 30 '13 at 16:17
  • Yes I am trying to avoid it alltogether thus the best approach seems to catch it and get a new IEnumerable handler for it. I need to preserve order, no need to allow for duplicates (it stores the same class with different values), they should be accessible by index but no need for replacement. – user2534406 Jun 30 '13 at 16:46
  • @user2534406: No, that's not the best approach - catching an exception isn't avoiding it, it's just catching it. If you need strict order preservation then the concurrent collections might not be good enough - in which case I'd suggest locking. You've said it's "not an option" but you've given no indication of why that's the case. – Jon Skeet Jun 30 '13 at 16:50