Вопрос о дизайне потока C #

Question

Прямо сейчас у меня есть приложение, представляющее собой конвейерный дизайн.На одном из первых этапов он считывает некоторые данные и файлы в поток.Есть несколько промежуточных этапов, которые что-то делают с потоком данных.И затем есть заключительный этап, который записывает поток куда-то.Все это происходит последовательно, один этап завершается, а затем переходят к следующему этапу.

Все это работало просто великолепно, но теперь объем данных начинает немного увеличиваться (потенциально сотни ГБ).Поэтому я думаю, что мне нужно будет что-то сделать, чтобы облегчить это.Моя первоначальная мысль - это то, по чему я ищу отзывы (будучи независимым разработчиком, мне просто негде поделиться идеей).

Я подумываю о создании Параллельного конвейера.Объект, который запускается из конвейера, создаст все этапы и запустит каждый из них в своем собственном потоке.Когда первая стадия доведет поток до некоторого определенного размера, она передаст этот поток на следующую стадию для обработки и запустит новый собственный поток, чтобы продолжить заполнение.Идея здесь заключается в том, что заключительным этапом будет закрытие потоков, поскольку на первом этапе создается новый, так что использование моей памяти будет снижено.

Итак, вопросы:1) Есть какие-нибудь мысли высокого уровня о направлениях для этого дизайна?2) Есть ли более простой подход, о котором вы можете подумать, который мог бы быть применим здесь?3) Существует ли что-нибудь, что делает что-то подобное, что я мог бы использовать повторно (не продукт, который я должен покупать)?

Спасибо,

Заглушенный

Answer 1

Модель производитель /потребитель - хороший способ действовать.И у Microsoft есть свои новые Параллельные расширения который должен обеспечить вам большую часть основной работы.Загляни в Задача объект.Доступен предварительный выпуск для .NET 3.5 / VS2008.

Ваша первая задача должна считывать блоки данных из вашего потока, а затем передавать их другим задачам.Затем разместите в середине столько задач, сколько логически уместно.Небольшие задачи (как правило) лучше.Единственное, на что вам нужно обратить внимание, - это убедиться, что последняя задача сохраняет данные в том порядке, в котором они были прочитаны (потому что все задачи в середине могут завершиться в порядке, отличном от того, в котором они были начаты).

Answer 2

Что касается предложенного вами дизайна, вам бы хотелось хорошенько ознакомиться с проблемы производителя / потребителя если вы еще этого не сделали.Вам понадобится хорошее понимание того, как использовать семафоры в такой ситуации.

Другой подход, который вы могли бы попробовать, - это создать несколько идентичных конвейеров, каждый в отдельном потоке.Вероятно, это было бы проще кодировать, потому что у него намного меньше межпотоковой связи.Однако, в зависимости от ваших данных, вы, возможно, не сможете разделить их на фрагменты таким образом.

Answer 3

На каждом этапе вы считываете весь фрагмент данных, выполняете манипуляции, а затем отправляете весь фрагмент на следующий этап?

Если это так, то вы используете технику "выталкивания", при которой вы переводите весь фрагмент данных на следующий этап.Способны ли вы управлять вещами в более потоковом режиме, таком как manor, используя технику "вытягивания"?Каждый этап представляет собой поток, и когда вы считываете данные из этого потока, он извлекает данные из предыдущего потока, вызывая read для него.По мере чтения каждого потока он считывает из предыдущего потока небольшие фрагменты, обрабатывает их и возвращает обработанные данные.Конечный поток определяет, сколько байтов нужно прочитать из предыдущего потока, и вам никогда не придется потреблять большие объемы памяти.Вот как работают приложения, подобные BizTalk.Есть несколько блогов о том, как работают конвейерные потоки BizTalk, и я думаю, что это может быть именно то, что вы хотите.

Вот запись в блоге, состоящая из нескольких частей, которая может показаться вам интересной:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5