Is the List<T>.AddRange() thread safe?

Question

Can I, without locking, safely call List.AddRange(r) from multiple threads? If not, what sort of trouble would I run into?

Answer 1

No, its documentation does not say it is thread safe, therefore it is not.

Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

As to what can go wrong, think about what AddRange(newItems) does:

• Check if there is enough space in the internal array
• If not:
  • Allocate a new array
  • Copy the current items to the new array
  • Set a field to point at the new array
• Copy the newItems to the correct local in the internal array
• Update the “count” field (this is used to control where the next item is inserted)

Now think what will happen if the above is mixed up with another all to AddRange() or even just a call to read an item.

Answer 2

No it is not thread-safe.

Thread A could call AddRange on your list. It could iterate partially over the collection and switch threads.

Thread B could call Add/Remove, etc. before Thread A has finished.

Answer 3

No it's not, but I'd like to add it's more efficient to do an myList.AddRange(...); within a lock than doing several lock (syncLock) { myList.Add(...) };.

Which sort of trouble would you run into? When one thread is adding an item while another is enumerating the list, List<T> will throw a certain exception because it does some internal versioning, as it wants to prevent us poor developers from hitting nasty side effects.

Also the List<T> internally keeps an array in which it stores its items. Maybe setting an item in an array is pretty atomic, but whenever the capacity of this array is reached, a new one will be created and the items will be copied over from the old one. So when a thread wants to add something while that copying takes place, you can imagine that things would go out of sync.

Answer 4

Until .NET Framework 4.0, no .NET collections are thread-safe. You will then be required to lock it before you access it in your code Collections and Synchronization (Thread Safety).

On the other hand, .NET Framework 4.0 introduces the new System.Collections.Concurrent namespace which includes fine-grained Thread-Safe Collections.

Finally, if you can use .NET Framework 4.0, I strongly recommend you do so for what you need, otherwise, make sure to lock the collection each time you want to modify or access it.

Besides, a static collection should be thread-safe, but beware, as the members are not guaranteed to be.

EDIT #1

After further verifications due to Steve Townsend's comment, I admit that there are three thread-safe collections within the .NET Framework starting with version 3.0:

1. SynchronizedCollection Generic Class;
2. SynchronizedKeyedCollection Generic Class;
3. SynchronizedReadOnlyCollection Generic Class.

I apologize, I just learned their exitense myself. =)

Answer 5

Depending on your usage, SynchronizedCollection could work.

You'd have no single-shot AddRange though. If you are only using this to seed the collection, you can do this as there is an IEnumerable constructor overload.