Конвейер (программное обеспечение)

В программной инженерии конвейер состоит из цепочки элементов обработки ( процессов , потоков , сопрограмм , функций и т. д. ), организованных таким образом, что выход каждого элемента является входом следующего. Концепция аналогична физическому конвейеру . Обычно между последовательными элементами обеспечивается некоторая буферизация . Информация, которая течет в этих конвейерах, часто представляет собой поток записей , байтов или битов , а элементы конвейера могут называться фильтрами . Это также называется шаблоном проектирования труб и фильтров , который является монолитным . Его преимуществами являются простота и низкая стоимость, а его недостатками являются отсутствие эластичности , отказоустойчивости и масштабируемости . ^[1] Соединение элементов в конвейер аналогично композиции функций .

В узком смысле конвейер является линейным и однонаправленным, хотя иногда этот термин применяется к более общим потокам. Например, в первую очередь однонаправленный конвейер может иметь некоторую связь в другом направлении, известную как обратный канал или бэкканал, как в лексерном взломе , или конвейер может быть полностью двунаправленным. Потоки с однонаправленными деревьями и направленными ациклическими топологиями графа ведут себя аналогично линейным конвейерам. Отсутствие циклов в таких потоках делает их простыми, и поэтому их можно свободно называть «конвейерами».

Конвейеры часто реализуются в многозадачной ОС , запуская все элементы одновременно с процессами и автоматически обслуживая запросы на чтение данных каждым процессом с данными, записанными вышестоящим процессом. Это можно назвать многопроцессорным конвейером. Таким образом, планировщик естественным образом переключает ЦП между процессами, чтобы минимизировать время его простоя. В других распространенных моделях элементы реализуются как легковесные потоки или как сопрограммы, чтобы уменьшить накладные расходы ОС, часто связанные с процессами. В зависимости от ОС потоки могут планироваться непосредственно ОС или менеджером потоков. Сопрограммы всегда планируются менеджером сопрограмм той или иной формы.

Запросы на чтение и запись обычно являются блокирующими операциями. Это означает, что выполнение исходного процесса при записи приостанавливается до тех пор, пока все данные не будут записаны в целевой процесс. Аналогично, выполнение целевого процесса при чтении приостанавливается до тех пор, пока хотя бы часть запрошенных данных не будет получена из исходного процесса. Это не может привести к взаимоблокировке , когда оба процесса будут бесконечно ждать ответа друг друга, поскольку по крайней мере один из процессов вскоре получит свой запрос, обслуженный операционной системой, и продолжит работу.

Для повышения производительности большинство операционных систем, реализующих каналы, используют буферы каналов , которые позволяют исходному процессу предоставлять больше данных, чем целевой процесс в данный момент может или хочет получить. В большинстве Unix и Unix-подобных операционных систем также доступна специальная команда, обычно называемая «буфер», которая реализует буфер канала потенциально гораздо большего и настраиваемого размера. Эта команда может быть полезна, если целевой процесс значительно медленнее исходного процесса, но желательно, чтобы исходный процесс завершил свою задачу как можно скорее. Например, если исходный процесс состоит из команды, которая считывает звуковую дорожку с компакт- диска , а целевой процесс состоит из команды, которая сжимает аудиоданные формы сигнала в формат типа MP3 . В этом случае буферизация всей дорожки в буфере канала позволит приводу компакт-дисков быстрее останавливаться и позволит пользователю извлечь компакт-диск из привода до завершения процесса кодирования.

Такая команда буфера может быть реализована с помощью системных вызовов для чтения и записи данных. Бесполезное активное ожидание можно избежать, используя такие возможности, как poll или select или многопоточность .

Некоторые примечательные примеры систем программного обеспечения для конвейеров включают в себя:

• RaftLib – Лицензия Apache 2.0 C/C++

CMS Pipelines — это порт идеи конвейера для систем VM/CMS и z/OS . Он поддерживает гораздо более сложные структуры конвейера, чем оболочки Unix, с шагами, принимающими несколько входных потоков и создающими несколько выходных потоков. (Такая функциональность поддерживается ядром Unix, но немногие программы используют ее, поскольку она усложняет синтаксис и режимы блокировки, хотя некоторые оболочки поддерживают ее посредством произвольного назначения дескриптора файла ).

Традиционные прикладные программы на операционных системах мэйнфреймов IBM не имеют стандартных входных и выходных потоков для перенаправления или конвейеризации. Вместо того, чтобы порождать процессы с помощью внешних программ, CMS Pipelines предлагает облегченный диспетчер для одновременного выполнения экземпляров более 200 встроенных программ, которые реализуют типичные утилиты UNIX и взаимодействуют с устройствами и службами операционной системы. В дополнение к встроенным программам CMS Pipelines определяет фреймворк, позволяющий писать пользовательские программы REXX с входными и выходными потоками, которые можно использовать в конвейере.

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

Помимо конвейеров на основе потока байтов, существуют также объектные конвейеры. В объектном конвейере обработка элементов выводит объекты вместо текста. PowerShell включает внутренний объектный конвейер, который передает объекты .NET между функциями в среде выполнения PowerShell. Каналы , найденные в языке программирования Limbo , являются другими примерами этой метафоры.

Графические среды, такие как RISC OS и ROX Desktop, также используют конвейеры. Вместо того, чтобы предоставлять диалоговое окно сохранения , содержащее файловый менеджер , позволяющий пользователю указать, куда программа должна записывать данные, RISC OS и ROX предоставляют диалоговое окно сохранения, содержащее значок (и поле для указания имени). Место назначения указывается путем перетаскивания значка. Пользователь может поместить значок в любое место, куда может быть помещен уже сохраненный файл, в том числе на значки других программ. Если значок помещен на значок программы, он загружается, и содержимое, которое в противном случае было бы сохранено, передается в стандартный поток ввода новой программы.

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

Концептуально этот метод можно использовать с обычным диалоговым окном сохранения, но это потребовало бы, чтобы программы пользователя имели очевидное и легкодоступное местоположение в файловой системе. Поскольку это часто не так, конвейеры GUI встречаются редко.

Название «конвейер» происходит от приблизительной аналогии с физическим водопроводом, поскольку трубопровод обычно ^[2] позволяет информации течь только в одном направлении, подобно тому, как вода часто течет по трубе.

Каналы и фильтры можно рассматривать как форму функционального программирования , использующую потоки байтов как объекты данных. Более конкретно, их можно рассматривать как особую форму монады для ввода-вывода . ^[3]

Концепция конвейера также является центральной в среде веб-разработки Cocoon или в любых реализациях XProc (стандарты W3C), где она позволяет изменять исходный поток перед его окончательным отображением.

Этот шаблон поощряет использование текстовых потоков в качестве ввода и вывода программ. Эта зависимость от текста должна учитываться при создании графических оболочек для текстовых программ.

• Анонимная трубка
• Компонентно-ориентированная разработка программного обеспечения
• Программирование на основе потока
• GStreamer для мультимедийного фреймворка, построенного на конвейерах плагинов
• Графический конвейер
• Итераторы
• Именованный канал — конструкция операционной системы, промежуточная между анонимным каналом и файлом.
• Конвейер (вычисления) для других компьютерных версий концепции.
• Сети процессов Кана для расширения концепции конвейера до более общей структуры направленного графа
• Pipeline (Unix) для получения подробной информации, специфичной для Unix
• Сантехник – «умные трубы», разработанные в рамках Plan 9
• Проблема производитель-потребитель – для аспектов реализации программных конвейеров
• Шаблон проектирования программного обеспечения
• Потоковая обработка
• XML-конвейер для обработки XML- файлов

• Обработка трубопроводов.
• Параллельное программирование: Знаете ли вы конвейерный параллелизм?