Can I, without locking, safely call List.AddRange(r) from multiple threads? If not, what sort of trouble would I run into?
相关问题
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
- How to know full paths to DLL's from .csproj f
No, its documentation does not say it is thread safe, therefore it is not.
As to what can go wrong, think about what AddRange(newItems) does:
Now think what will happen if the above is mixed up with another call to AddRange() or even just a call to read an item.
No it's not, but I'd like to add it's more efficient to do an
myList.AddRange(...);
within a lock than doing severallock (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.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 anIEnumerable
constructor overload.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.
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 codeCollections and Synchronization (Thread Safety)
.On the other hand, .NET Framework 4.0 introduces the new
System.Collections.Concurrent
namespace which includes fine-grainedThread-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:
I apologize, I just learned their exitense myself. =)