Трубопровод (программное обеспечение) - Pipeline (software)

Эта статья о программных конвейерах в целом. Для исходной реализации оболочек см. Pipeline (Unix) .

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

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

Реализация

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

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

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

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

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

ВМ / CMS и z / OS

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

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

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

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

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

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

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

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

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

Прочие соображения

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

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

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

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

Смотрите также

Ноты

  1. ^ Есть исключения, например, сигналы "сломанная труба".
  2. ^ "Монадический ввод-вывод и программирование оболочки UNIX" .

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