ConcurrentBag позволит нескольким потокам добавлять и удалять элементы из пакета. Возможно, что нить добавит элемент в сумку, а затем вернет тот же самый элемент обратно. В нем говорится, что ConcurrentBag неупорядочен, но как неупорядочен он? В одной нити сумка действует как стек. Неупорядочено ли "не похоже на связанный список"?
Что такое реальный мир для ConcurrentBag?
Сумки действительно полезны для отслеживания количества экземпляров. Например, если вы хотите сохранить запись о том, на каких хостах вы обслуживаете веб-запросы, вы можете добавить свой IP-адрес в сумку при запуске обслуживания запроса и удалить его, когда это будет сделано.
Использование сумки позволит вам сразу рассказать, какие IP-адреса вы сейчас обслуживаете. Он также позволит вам быстро запросить, обслуживаете ли вы данный IP-адрес.
Если вы используете набор для этого, а не мешок, то наличие нескольких одновременных запросов с одного и того же IP-адреса испортит ваш учет.
Поскольку ConcurrentBag не имеет порядка, преимущество в производительности по сравнению с ConcurrentStack/Queue. Он реализуется Microsoft как локальное хранилище потоков. Поэтому каждый поток, добавляющий элементы, делает это в своем собственном пространстве. При извлечении элементов они поступают из локального хранилища. Только когда это пусто, поток перехватывает элемент из другого хранилища потоков. Поэтому вместо простого списка ConcurrentBag представляет собой распределенный список элементов. И он почти свободен и должен лучше масштабироваться при высоком уровне параллелизма.
К сожалению, в.NET 4.0 была проблема с производительностью (исправлена в 4.5), см. Http://ayende.com/blog/156097/the-high-cost-of-concurrentbag-in-net-4-0
Все, что вам нужно, чтобы отслеживать, что там и не требуется произвольный доступ или гарантированный заказ. Если у вас есть поток, который добавляет элементы для обработки, и поток, который удаляет элементы для их обработки, параллельный пакет будет работать хорошо, если вам все равно, что они обрабатываются в порядке FIFO.
Благодаря @Chris Jester-Young я придумал хороший реальный мир, сценарий, который действительно относится к проекту, над которым я работаю.
Найти - процесс - магазин
Найти - потоки 1 и 2 настроены на поиск или очистку данных (файловая система, сеть и т.д.). Эти результаты сохраняются в ConcurrentBag1.
Процесс - потоки 3 и 4 настроены на выведение из ConcurrentBag1, очистку/преобразование/обработку данных, а затем сохранение результатов в ConcurrentBag2.
Store - потоки 5 настроены на сбор результатов из ConcurrentBag2 и сохранение результатов в SQL.