Why isn't there a ConcurrentList<T>

Question

The new namespace System.Collections.Concurrent contains concurrent collections for dictionary, queue and stack among other classes. Anyone know why is it that there is no ConcurrentList?

UPDATE

I've posted a new question explaining my current scenario. I preferred that to changing the whole sense of the original question. Here's the link to the new question.

Solution 1

Random access doesn't make much sense on a data structure that's changed from another thread.

If you look at the concurrent collections, you'll notice that their interface is specifically designed to work well with multi threaded access. I can't think of a useful list-like interface that works well with multithreaded code.

Random multi threaded access can make sense if the elements are never moved, but then you have an array.

Solution 2

If two threads added items simultaneously what expectation of 'order' would you have? ConcurrentBag is more appropriate if all you want is a collection of items.

Comments

[stuartd]

Possible duplicate of No ConcurrentList<T> in .Net 4.0?

[supercat]

There are a variety of useful subsets of IList<T> which could be implemented in thread-safe fashion. For example, one could have a collection which behaves mostly like an array but also includes an Add method which returns the index of the newly added item. Arrays can't change size, so such a collection could fulfill roles that an array cannot.

[supercat]

If T were constrained to class, could one use CompareExchange to change the last thing in the list from null to the new item and then use CompareExchange to update _count? If the first CompareExchange fails, retry the operation using the larger of _count and (one plus the previous _count). If the second fails, retry if _count is less than the new value.

[Panagiotis Kanavos]

ConcurrentBag is not appropriate for general use. It's a very specialized class, used to provide quick thread-local storage and access.

[Wolfzoon]

@supercat there is no such thing as necro, so... Your scenario seems like it could just use ConcurrentQueue/Stack, if all you want is to safely add to the end of an 'array'. You can still enumerate them without popping, and they stay in the same order.

[supercat]

@Wolfzoon: I don't think those types support access by index, do they? If the Add method of an IList-like object returned the index of the new item, then multiple threads could simultaneously and independently, without conflicts, create new entries in the list and be able to update them continuously without interference, provided that any particular item would only be updated by the thread that had added it.

[supercat]

@Wolfzoon: I suppose one could use a ConcurrentDictionary<int,Whatever> along with a static int that is used as a "ticket dispenser" with Interlocked.Add to generate keys. Probably not as efficient as a more list-like design could be, but it exists as a pre-fabricated type.