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

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

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

Выполнение

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

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

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

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

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

RaftLib — лицензия C/C++ Apache 2.0

ВМ/CMS и z/OS

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

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

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

Конвейеры объектов

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

Конвейеры в графических интерфейсах

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

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

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

Другие соображения

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

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

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

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

См. также

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

Примечания

^ Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454 .
^ Есть исключения, например сигналы «лопнувшей трубы».
^ «Монадический ввод-вывод и программирование оболочки UNIX». Архивировано 9 ноября 2020 г. на Wayback Machine .

Внешние ссылки

[1] Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа. 2020. ISBN 978-1492043454 .

[2] Есть исключения, например сигналы «лопнувшей трубы».

[3] «Монадический ввод-вывод и программирование оболочки UNIX». Архивировано 9 ноября 2020 г. на Wayback Machine .

[1]

[2]

[3]