ConcurrentList, реализующий IList, может отсутствовать в пространстве имен Collections.Concurrent из-за целых Parallel.For и Parallel.ForEach методов класса.Можно сказать, что они могут использоваться для обработки любого списка как параллельного, чтобы быстро перечислять список и выполнять действия с его элементами.
Может быть, не предоставив ConcurrentList, они имели в виду или думали, что если Parralel.For не сможет помочь, потребуется использовать не IList, а какой-то другой вид коллекций, такой как стек или очередь, или даже Bag или даже Dictionary
Я бы согласился с этим дизайном, потому что работа с индексируемой коллекцией в условиях многопоточности звучит как очень подверженная ошибкам и плохая конструкция.Какова цель знания индекса элемента, если коллекция может быть изменена в любое время, и индекс будет признан недействительным, в таких случаях, когда есть несколько читателей - писателей, мне совершенно ясно, что очередь или стек обычно лучше всего подходят для коллекций, илиСумка тоже может быть хорошей.Словарь можно использовать также потому, что его индексы не становятся недействительными при добавлении элементов в коллекцию, и если вам нужен параллельный доступ к списку, вы получаете свои Parralel.For методы
То, что я считаю действительно странным - http://msdn.microsoft.com/en-us/library/dd381935.aspxздесь мы можем прочитать о классе ConcurrentLinkedList, но я не могу найти его в System.dll, там есть только Bag и BlockingCollection.
Я бы также сказал, что есть вероятность, по крайней мере, 95%, что любое из двух истинноВаша проблема
- Методы параллельного класса лучше, чем ConcurrentList
- Существующие коллекции Concurrent будут лучшими коллекциями, чем ConcurrentList
Я бы также сказал, чтоне предоставляя ConcurrentList, они спасли разработчиков, которые по ошибке выбрали ConcurrentList, чтобы решить свои проблемы, не допустив много ошибок, и сэкономили много времени, заставляя разработчиков использовать существующие коллекции Concurrent.