Grupo de subprocesos

Un grupo de subprocesos de muestra (recuadros verdes) con tareas en espera (azul) y tareas completadas (amarillo)

En programación de computadoras , un grupo de subprocesos es un patrón de diseño de software para lograr la concurrencia de ejecución en un programa de computadora. A menudo también llamado modelo de trabajadores replicados o trabajador-equipo , ^[1] un grupo de subprocesos mantiene varios subprocesos esperando que el programa de supervisión asigne tareas para su ejecución simultánea . Al mantener un grupo de subprocesos, el modelo aumenta el rendimiento y evita la latencia en la ejecución debido a la frecuente creación y destrucción de subprocesos para tareas de corta duración. ^[2] El número de subprocesos disponibles se ajusta a los recursos informáticos disponibles para el programa, como una cola de tareas paralelas después de la finalización de la ejecución.

Rendimiento

El tamaño de un grupo de subprocesos es el número de subprocesos que se mantienen en reserva para ejecutar tareas. Suele ser un parámetro ajustable de la aplicación, ajustado para optimizar el rendimiento del programa. ^[3] Decidir el tamaño óptimo del grupo de subprocesos es crucial para optimizar el rendimiento.

Un beneficio de un grupo de subprocesos sobre la creación de un nuevo subproceso para cada tarea es que la sobrecarga de creación y destrucción de subprocesos se restringe a la creación inicial del grupo, lo que puede resultar en un mejor rendimiento y una mejor estabilidad del sistema . Crear y destruir un hilo y sus recursos asociados puede ser un proceso costoso en términos de tiempo. Sin embargo, un número excesivo de subprocesos en reserva desperdicia memoria, y el cambio de contexto entre los subprocesos ejecutables provoca penalizaciones en el rendimiento. Una conexión de socket a otro host de red, que puede tomar muchos ciclos de CPU para desconectarse y restablecerse, se puede mantener de manera más eficiente asociándola con un hilo que permanece en el transcurso de más de una transacción de red.

El uso de un grupo de subprocesos puede ser útil incluso dejando de lado el tiempo de inicio del subproceso. Hay implementaciones de grupos de subprocesos que hacen que sea trivial poner en cola el trabajo, controlar la concurrencia y sincronizar subprocesos a un nivel superior al que se puede hacer fácilmente cuando se administran subprocesos manualmente. ^[4]^[5] En estos casos, los beneficios de rendimiento del uso pueden ser secundarios.

Normalmente, un grupo de subprocesos se ejecuta en una sola computadora. Sin embargo, los grupos de subprocesos están relacionados conceptualmente con las granjas de servidores en las que un proceso maestro, que podría ser un grupo de subprocesos en sí mismo, distribuye las tareas a los procesos de trabajo en diferentes computadoras, para aumentar el rendimiento general. Problemas vergonzosamente paralelos son muy susceptibles de este enfoque. ^{[ cita requerida ]}

El número de subprocesos puede ajustarse dinámicamente durante la vida útil de una aplicación en función del número de tareas en espera. Por ejemplo, un servidor web puede agregar subprocesos si ingresan numerosas solicitudes de páginas web y puede eliminar subprocesos cuando esas solicitudes disminuyen. ^{[ disputado - discutir ]} El costo de tener un grupo de subprocesos más grande es un mayor uso de recursos. El algoritmo utilizado para determinar cuándo crear o destruir subprocesos afecta el rendimiento general:

Crear demasiados subprocesos desperdicia recursos y cuesta tiempo crear los subprocesos no utilizados.
Destruir demasiados subprocesos requiere más tiempo después para volver a crearlos.
Crear subprocesos con demasiada lentitud puede resultar en un rendimiento deficiente del cliente (tiempos de espera prolongados).
La destrucción de subprocesos con demasiada lentitud puede privar de recursos a otros procesos.

En idiomas

En Go no operamos subprocesos sino goroutines (más baratos, multiplexados en subprocesos del sistema), existe un patrón similar "grupo de trabajadores". ^[6]^[7]^[8]

Ver también

Referencias

^ Garg, Rajat P. y Sharapov, Ilya Techniques for Optimizing Applications - High Performance Computing Prentice-Hall 2002, p. 394
^ Holub, Allen (2000). Domesticar los hilos de Java . Presione. pag. 209.
^ Yibei Ling; Tracy Mullen; Xiaola Lin (abril de 2000). "Análisis del tamaño óptimo del grupo de subprocesos". Revisión de sistemas operativos ACM SIGOPS . 34 (2): 42–55. doi : 10.1145 / 346152.346320 . S2CID 14048829 .
^ "Clase QThreadPool | Qt Core 5.13.1" .
^ "GitHub - vit-vit / CTPL: biblioteca de grupo de subprocesos C ++ moderna y eficiente" . 2019-09-24.
^ "Ir por ejemplo: grupos de trabajadores" . gobyexample.com . Consultado el 27 de julio de 2021 .
^ "Effective Go - El lenguaje de programación Go" . golang.org . Consultado el 27 de julio de 2021 . Otro enfoque que administra bien los recursos es iniciar un número fijo de rutinas de manejo, todas leyendo desde el canal de solicitud. El número de goroutines limita el número de llamadas simultáneas a procesar.
^ "El caso de un grupo de trabajadores de Go - brandur.org" . brandur.org . Consultado el 27 de julio de 2021 . Cuando se trata de la cuestión de cuáles son las construcciones correctas para la simultaneidad que un lenguaje debería exponer a los desarrolladores, soy un verdadero creyente de que los canales y rutinas de Go son lo mejor posible. Logran un buen equilibrio entre potencia y flexibilidad, al mismo tiempo que evitan la propensión a los puntos muertos que verías en un modelo pthread, el infierno de mantenimiento introducido por las devoluciones de llamada o la increíble sobrecarga conceptual de las promesas.

enlaces externos

" Query by Slice, Parallel Execute, and Join: A Thread Pool Pattern in Java " por Binildas CA
" Grupos de subprocesos y colas de trabajo " de Brian Goetz
" Un método de agrupación de hilos de trabajo " por Pradeep Kumar Sahu
" Work Queue " de Uri Twig: demostración de código C ++ de subprocesos agrupados que ejecutan una cola de trabajo.
" Encadenamiento de ejecución y agrupación de subprocesos de Windows "
" Smart Thread Pool " de Ami Bar
" Programación del grupo de subprocesos en .NET Framework " por David Carmona
" El grupo de subprocesos y los métodos asincrónicos " por Jon Skeet
" Creación de un grupo de subprocesos de bloqueo de notificaciones en Java " por Amir Kirsh
" Programación práctica de subprocesos con Python: grupos de subprocesos y colas " por Noah Gift
" Optimización de estrategias de agrupación de subprocesos para CORBA en tiempo real " por Irfan Pyarali, Marina Spivak, Douglas C. Schmidt y Ron Cytron
" Cancelación diferida. Un patrón de comportamiento " por Philipp Bachmann
" Un grupo de subprocesos C ++ 17 para la informática científica de alto rendimiento " por Barak Shoshany

[1] Garg, Rajat P. y Sharapov, Ilya Techniques for Optimizing Applications - High Performance Computing Prentice-Hall 2002, p. 394

[2] Holub, Allen (2000). Domesticar los hilos de Java . Presione. pag. 209.

[ACM,_Thread_pool_size-3] Yibei Ling; Tracy Mullen; Xiaola Lin (abril de 2000). "Análisis del tamaño óptimo del grupo de subprocesos". Revisión de sistemas operativos ACM SIGOPS . 34 (2): 42–55. doi : 10.1145 / 346152.346320 . S2CID 14048829 .

[4] "Clase QThreadPool | Qt Core 5.13.1" .

[5] "GitHub - vit-vit / CTPL: biblioteca de grupo de subprocesos C ++ moderna y eficiente" . 2019-09-24.

[6] "Ir por ejemplo: grupos de trabajadores" . gobyexample.com . Consultado el 27 de julio de 2021 .

[7] "Effective Go - El lenguaje de programación Go" . golang.org . Consultado el 27 de julio de 2021 . Otro enfoque que administra bien los recursos es iniciar un número fijo de rutinas de manejo, todas leyendo desde el canal de solicitud. El número de goroutines limita el número de llamadas simultáneas a procesar.

[8] "El caso de un grupo de trabajadores de Go - brandur.org" . brandur.org . Consultado el 27 de julio de 2021 . Cuando se trata de la cuestión de cuáles son las construcciones correctas para la simultaneidad que un lenguaje debería exponer a los desarrolladores, soy un verdadero creyente de que los canales y rutinas de Go son lo mejor posible. Logran un buen equilibrio entre potencia y flexibilidad, al mismo tiempo que evitan la propensión a los puntos muertos que verías en un modelo pthread, el infierno de mantenimiento introducido por las devoluciones de llamada o la increíble sobrecarga conceptual de las promesas.

[1]