В программной инженерии , А трубопровод состоит из цепочки элементов обработки ( процессы , потоки , сопрограммы , функции , и т.д. ), расположено таким образом , что выходной сигнал каждого элемента поступает на входе следующих; имя по аналогии с физическим конвейером . Обычно между последовательными элементами обеспечивается некоторая буферизация . Информация , которая течет в этих трубопроводах часто поток из записей , байтов , или битов , а элементы трубопровода можно назвать фильтры; это также называется шаблоном проектирования каналов и фильтров . Соединение элементов в конвейер аналогично композиции функций .
В более узком смысле, конвейер является линейным и однонаправленным, хотя иногда этот термин применяется к более общим потокам. Например, в первую очередь в одном направлении трубопровода может иметь некоторую связь в другом направлении, известную как обратный канал или 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 и ROX предоставляют диалоговое окно сохранения, содержащее значок (и поле для указания имени). Место назначения указывается путем перетаскивания значка. Пользователь может перетащить значок в любое место, где может быть сброшен уже сохраненный файл, в том числе на значки других программ. Если значок перетаскивается на значок программы, он загружается, и содержимое, которое в противном случае было бы сохранено, передается в стандартный поток ввода новой программы.
Например, пользователь, просматривающий всемирную сеть, может натолкнуться на сжатое изображение в формате .gz, которое он хочет отредактировать и повторно загрузить. Используя конвейеры графического интерфейса пользователя, они могли перетащить ссылку на свою программу разархивирования, перетащить значок, представляющий извлеченное содержимое, в свой редактор изображений , отредактировать его, открыть диалоговое окно «Сохранить как» и перетащить его значок в свою программу для загрузки.
Концептуально этот метод можно использовать с обычным диалоговым окном сохранения, но для этого потребуется, чтобы программы пользователя имели очевидное и легкодоступное место в файловой системе, к которому можно было бы перейти. На практике это часто не так, поэтому конвейеры с графическим интерфейсом пользователя встречаются редко.
Прочие соображения
Название «трубопровод» происходит от грубой аналогии с физическим водопроводом в том смысле, что трубопровод обычно [1] позволяет информации течь только в одном направлении, как вода часто течет по трубе.
Каналы и фильтры можно рассматривать как форму функционального программирования , использующего потоки байтов в качестве объектов данных; более конкретно, их можно рассматривать как особую форму монады для ввода-вывода . [2]
Концепция трубопровода также играет центральную роль в кокон веб - разработки базы или любой XProc (стандарты W3C) реализациях, где она позволяет поток исходного быть модифицирован до возможного отображения.
Этот шаблон поощряет использование текстовых потоков в качестве ввода и вывода программ. Эту зависимость от текста следует учитывать при создании графических оболочек для текстовых программ.
Смотрите также
- Анонимная труба
- Компонентная разработка программного обеспечения
- Программирование на основе потоков
- GStreamer для мультимедийного фреймворка, построенного на конвейерах плагинов
- Графический конвейер
- Итераторы
- Именованный канал , промежуточная конструкция операционной системы для анонимного канала и файла.
- Конвейер (вычисления) для других компьютерных версий концепции.
- Технологические сети Кана для расширения концепции конвейера до более общей структуры ориентированного графа
- Pipeline (Unix) для подробностей, относящихся к Unix
- Сантехник - «умные трубы», разработанные в рамках Plan 9
- Проблема производителя-потребителя для аспектов реализации программных конвейеров
- Шаблон проектирования программного обеспечения
- Потоковая обработка
- XML-конвейер для обработки файлов XML
Заметки
- ^ Есть исключения, например, сигналы "сломанная труба".
- ^ "Монадический ввод-вывод и программирование оболочки UNIX" .
Внешние ссылки
- Трубопроводная обработка.
- Параллельное программирование: знаете ли вы о конвейерном параллелизме?