Articulo de referencia

Pipeline (software)

En ingeniería de software , una tubería consiste en una cadena de elementos de procesamiento ( procesos , hilos , corrutinas , funciones , etc. ), organizados de manera que la s...

En ingeniería de software , una tubería consiste en una cadena de elementos de procesamiento ( procesos , hilos , corrutinas , funciones , etc. ), organizados de manera que la salida de cada elemento sea la entrada del siguiente. El concepto es análogo a una tubería física . Por lo general, se proporciona cierta cantidad de almacenamiento en búfer entre elementos consecutivos. La información que fluye en estas tuberías suele ser un flujo de registros , bytes o bits , y los elementos de una tubería pueden llamarse filtros . Esto también se conoce como el patrón de diseño de tuberías y filtros, que es monolítico . Sus ventajas son la simplicidad y el bajo costo, mientras que sus desventajas son la falta de elasticidad , tolerancia a fallos y escalabilidad . [ 1 ] Conectar elementos en una tubería es análogo a la composición de funciones .

En sentido estricto, una tubería es lineal y unidireccional, aunque a veces el término se aplica a flujos más generales. Por ejemplo, una tubería principalmente unidireccional puede tener comunicación en la dirección opuesta, conocida como canal de retorno o backchannel, como en el truco del analizador léxico , o puede ser completamente bidireccional. Los flujos con árboles unidireccionales y topologías de grafos acíclicos dirigidos se comportan de forma similar a las tuberías lineales. La ausencia de ciclos en estos flujos los simplifica, por lo que se les puede denominar informalmente "tuberías".

Implementación

Las tuberías se implementan a menudo en sistemas operativos multitarea , lanzando todos los elementos simultáneamente como procesos y atendiendo automáticamente las solicitudes de lectura de datos de cada proceso con los datos escritos por el proceso anterior. Esto se conoce como tubería multiproceso. De esta forma, el planificador distribuye naturalmente la CPU entre los procesos para minimizar su tiempo de inactividad. En otros modelos comunes, los elementos se implementan como hilos ligeros o como corrutinas para reducir la sobrecarga del sistema operativo que suelen generar los procesos. Dependiendo del sistema operativo, los hilos pueden ser programados directamente por el sistema operativo o por un gestor de hilos. Las corrutinas siempre son programadas por un gestor de corrutinas.

Las solicitudes de lectura y escritura suelen ser operaciones bloqueantes. Esto significa que la ejecución del proceso de origen, al escribir, se suspende hasta que se hayan escrito todos los datos en el proceso de destino. Del mismo modo, la ejecución del proceso de destino, al leer, se suspende hasta que se hayan obtenido al menos algunos de los datos solicitados del proceso de origen. Esto evita un interbloqueo , donde ambos procesos esperarían indefinidamente la respuesta del otro, ya que al menos uno de ellos pronto verá su solicitud atendida por el sistema operativo y continuará su ejecución.

Para optimizar el rendimiento, la mayoría de los sistemas operativos que implementan tuberías utilizan búferes de tubería , que permiten al proceso de origen proporcionar más datos de los que el proceso de destino puede o desea recibir. En la mayoría de los sistemas operativos Unix y similares, también está disponible un comando especial, generalmente llamado "buffer", que implementa un búfer de tubería de tamaño potencialmente mucho mayor y configurable. Este comando puede ser útil si el proceso de destino es significativamente más lento que el proceso de origen, pero se desea que este último complete su tarea lo antes posible. Por ejemplo, si el proceso de origen consiste en un comando que lee una pista de audio de un CD y el proceso de destino consiste en un comando que comprime los datos de audio de la forma de onda a un formato como MP3 . En este caso, almacenar la pista completa en un búfer de tubería permitiría que la unidad de CD se detuviera más rápidamente y que el usuario pudiera extraer el CD de la unidad antes de que finalice el proceso de codificación.

Este comando de búfer se puede implementar utilizando llamadas al sistema para leer y escribir datos. Se puede evitar la espera activa innecesaria utilizando herramientas como sondeo , selección o multihilo .

Algunos ejemplos notables de sistemas de software para pipelines incluyen:

  • RaftLib – Licencia Apache 2.0 para C/C++

VM/CMS y z/OS

CMS Pipelines es una adaptación del concepto de pipeline a los sistemas VM/CMS y z/OS . Admite estructuras de pipeline mucho más complejas que los intérpretes de comandos de Unix, con pasos que toman múltiples flujos de entrada y producen múltiples flujos de salida. (El kernel de Unix admite esta funcionalidad, pero pocos programas la utilizan debido a la complejidad de su sintaxis y a los modos de bloqueo que genera, aunque algunos intérpretes de comandos la admiten mediante la asignación arbitraria de descriptores de archivo ).

Los programas de aplicación tradicionales en los sistemas operativos de mainframes de IBM carecen de flujos de entrada y salida estándar que permitan la redirección o el enrutamiento. En lugar de generar procesos con programas externos, CMS Pipelines incorpora un despachador ligero para ejecutar simultáneamente instancias de más de 200 programas integrados que implementan utilidades típicas de UNIX e interactúan con dispositivos y servicios del sistema operativo. Además de los programas integrados, CMS Pipelines define un marco que permite la ejecución de programas REXX escritos por el usuario con flujos de entrada y salida que pueden utilizarse en el pipeline.

Los datos en los mainframes de IBM suelen residir en un sistema de archivos orientado a registros , y los dispositivos de E/S conectados operan en modo de registro en lugar de modo de flujo. Por consiguiente, los datos en CMS Pipelines se gestionan en modo de registro. En el caso de los archivos de texto, un registro contiene una línea de texto. En general, CMS Pipelines no almacena los datos en búfer, sino que los transmite de forma secuencial de un programa a otro. Esto garantiza un flujo de datos determinista a través de una red de pipelines interconectados.

Canalizaciones de objetos

Además de las canalizaciones basadas en flujos de bytes, también existen canalizaciones de objetos. En una canalización de objetos, los elementos de procesamiento generan objetos en lugar de texto. PowerShell incluye una canalización de objetos interna que transfiere objetos .NET entre funciones dentro del entorno de ejecución de PowerShell. Los canales , presentes en el lenguaje de programación Limbo , son otros ejemplos de esta metáfora.

Pipelines en interfaces gráficas de usuario

Los entornos gráficos como RISC OS y ROX Desktop también utilizan tuberías. En lugar de proporcionar un cuadro de diálogo para guardar archivos con un administrador de archivos que permita al usuario especificar dónde debe escribir los datos un programa , RISC OS y ROX proporcionan un cuadro de diálogo con un icono (y un campo para especificar el nombre). El destino se especifica arrastrando y soltando el icono. El usuario puede soltar el icono en cualquier lugar donde se podría soltar un archivo ya guardado, incluso sobre los iconos de otros programas. Si el icono se suelta sobre el icono de un programa, este se carga y el contenido que de otro modo se habría guardado se pasa a través del flujo de entrada estándar del nuevo programa.

Por ejemplo, un usuario que navega por internet podría encontrar una imagen comprimida en formato .gz que desee editar y volver a subir. Mediante interfaces gráficas de usuario (GUI), podría arrastrar el enlace a su programa de descompresión, arrastrar el icono que representa el contenido extraído a su editor de imágenes , editarlo, abrir el cuadro de diálogo "Guardar como" y arrastrar su icono a su software de carga de archivos.

Conceptualmente, este método podría utilizarse con un cuadro de diálogo de guardado convencional, pero esto requeriría que los programas del usuario tuvieran una ubicación obvia y fácilmente accesible en el sistema de archivos. Dado que esto no suele ser así, las canalizaciones con interfaz gráfica de usuario son poco comunes.

Otras consideraciones

El nombre "pipeline" proviene de una analogía aproximada con la fontanería física, ya que un pipeline generalmente [ 2 ] permite que la información fluya en una sola dirección, como el agua a menudo fluye en una tubería.

Las tuberías y los filtros pueden considerarse una forma de programación funcional , que utiliza flujos de bytes como objetos de datos. Más específicamente, pueden verse como una forma particular de mónada para E/S . [ 3 ]

El concepto de pipeline también es fundamental para el marco de desarrollo web Cocoon o para cualquier implementación de XProc (los estándares del W3C), donde permite modificar un flujo de origen antes de su visualización final.

Este patrón fomenta el uso de flujos de texto como entrada y salida de programas. Esta dependencia del texto debe tenerse en cuenta al crear interfaces gráficas para programas de texto.

Véase también

Notas

  1. Fundamentos de la arquitectura de software: Un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  2. Existen excepciones, como las señales de "tubería rota".
  3. "E/S monádica y programación de shell UNIX" Archivado el 9 de noviembre de 2020 en Wayback Machine .
  • Procesamiento en cadena. Archivado el 19 de enero de 2021 en Wayback Machine.
  • Programación paralela: ¿Conoces el paralelismo en pipeline?