Насколько я понимаю, вы в настоящее время предоставляете две гарантии неизменности:
- Существует неизменная ссылка (и) на
List<Bar> объект.
- Сам тип
Bar является неизменным или, по договоренности, его экземпляры не видоизменяются после добавления в список.
Ничего из этого не достаточно, чтобы справиться с любыми параллельными сценариями чтения / записи, поскольку сам List<T> тип не является поточно-ориентированным.
- Если у вас несколько несинхронизированных писателей, вы можете испортить список.
- Если у вас есть один писатель с читателями в других потоках, вы, вероятно, не повредите список. С другой стороны, читатели не будут работать правильно. Если вам повезет, повторение списка в середине записи вызовет исключение «Коллекция изменена во время перечисления». Если нет, ваша программа молча потеряет свою функциональную корректность.
Теперь вы можете попробовать синхронизировать доступ к списку с блокировками, ReaderWriterLockSlims и т. Д. То, как вы это сделаете, будет специфичным для отношений производитель / потребитель в вашей конкретной ситуации. Например, вы можете заблокировать мутацию во время перечисления одним из следующих способов:
- Задержать попытку видоизменения до тех пор, пока существует активный нераспределенный перечислитель.
- Каждый раз, когда запрашивается перечислитель, пишите блок. Скопируйте список в другой список; верните его перечислитель, а затем разблокируйте авторов.
Но я бы посоветовал, если вы работаете в .NET 4.0, взглянуть на классы поточно-ориентированных коллекций в пространстве имен System.Collections.Concurrent. В частности, вы можете найти класс BlockingCollection<T> именно тем, что вам нужно.
Наконец, я хотел бы взглянуть на общий дизайн, чтобы увидеть, сможете ли вы решить эту проблему без блокировки.