Un subproceso de ejecución a menudo se considera la unidad de procesamiento más pequeña en la que trabaja un planificador.
Un proceso puede tener varios subprocesos de ejecución que se ejecutan de forma asíncrona.
Esta ejecución asíncrona trae la capacidad de cada subproceso de manejar un trabajo o servicio en particular de forma independiente. Por lo tanto, varios subprocesos que se ejecutan en un proceso manejan sus servicios, lo que en general constituye la capacidad completa del proceso.
En este artículo, tocaremos la base de los fundamentos de los subprocesos y desarrollaremos la comprensión básica necesaria para aprender la práctica. aspectos de los subprocesos de Linux.
Serie de subprocesos de Linux:parte 1 (este artículo), parte 2, parte 3.
¿Por qué se requieren subprocesos?
Ahora, uno se preguntaría ¿por qué necesitamos múltiples subprocesos en un proceso? ¿Por qué no se puede usar un proceso con un solo subproceso principal (predeterminado) en todas las situaciones?
Bueno, para responder a esto, consideremos un ejemplo:
Supongamos que hay un proceso, que recibe entradas en tiempo real y correspondientes a cada entrada tiene que producir una salida determinada. Ahora bien, si el proceso no es de subprocesos múltiples, es decir, si el proceso no involucra subprocesos múltiples, entonces todo el procesamiento en el proceso se vuelve síncrono. Esto significa que el proceso toma una entrada, la procesa y produce una salida.
La limitación en el diseño anterior es que el proceso no puede aceptar una entrada hasta que termine de procesar la anterior y, en caso de que el procesamiento de una entrada tarde más de lo esperado, la aceptación de más entradas se suspende.
Para considerar el impacto de la limitación anterior, si mapeamos el ejemplo genérico anterior con un proceso de servidor de socket que puede aceptar conexiones de entrada, procesarlas y proporcionar salida al cliente de socket. Ahora, si al procesar cualquier entrada, si el proceso del servidor toma más tiempo del esperado y, mientras tanto, llega otra entrada (solicitud de conexión) al servidor de socket, entonces el proceso del servidor no podrá aceptar la nueva conexión de entrada porque ya está atascada. procesando la antigua conexión de entrada. Esto puede conducir a un tiempo de espera de conexión en el cliente de socket que no se desea en absoluto.
Esto muestra que el modelo de ejecución síncrono no se puede aplicar en todas partes y, por lo tanto, era el requisito del modelo de ejecución asíncrono que se implementa mediante el uso de subprocesos.
Diferencia entre hilos y procesos
Las siguientes son algunas de las principales diferencias entre el hilo y los procesos:
- Los procesos no comparten su espacio de direcciones mientras que los subprocesos que se ejecutan bajo el mismo proceso comparten el espacio de direcciones.
- Desde el punto anterior, está claro que los procesos se ejecutan independientemente unos de otros y que la sincronización entre procesos la realiza el kernel, mientras que, por otro lado, la sincronización de subprocesos debe ser atendida por el proceso bajo el cual se ejecutan los subprocesos
- El cambio de contexto entre subprocesos es rápido en comparación con el cambio de contexto entre procesos
- La interacción entre dos procesos se logra solo a través de la comunicación estándar entre procesos, mientras que los subprocesos que se ejecutan bajo el mismo proceso pueden comunicarse fácilmente ya que comparten la mayoría de los recursos como memoria, segmento de texto, etc.
Hilos de usuario frente a hilos del kernel
Los subprocesos pueden existir tanto en el espacio del usuario como en el espacio del núcleo.
Un espacio de usuario los subprocesos se crean, controlan y destruyen utilizando bibliotecas de subprocesos de espacio de usuario. Estos subprocesos no son conocidos por el núcleo y, por lo tanto, el núcleo no está involucrado en su procesamiento. Estos subprocesos siguen la multitarea cooperativa en la que un subproceso libera la CPU por su propia voluntad, es decir, el programador no puede adelantarse al subproceso. Las ventajas de los subprocesos de espacio de usuario es que el cambio entre dos subprocesos no implica mucha sobrecarga y generalmente es muy rápido, aunque en el lado negativo, ya que estos subprocesos siguen la multitarea cooperativa, por lo que si un subproceso se bloquea, todo el proceso se bloquea.
Un espacio del núcleo hilo es creado, controlado y destruido por el núcleo. Por cada subproceso que existe en el espacio del usuario, existe un subproceso del kernel correspondiente. Dado que estos subprocesos son administrados por el núcleo, siguen una multitarea preventiva en la que el programador puede adelantarse a un subproceso en ejecución con un subproceso de mayor prioridad que está listo para la ejecución. La principal ventaja de los subprocesos del kernel es que incluso si uno de los subprocesos se bloquea, todo el proceso no se bloquea, ya que los subprocesos del kernel siguen una programación preventiva, mientras que, en el lado negativo, el cambio de contexto no es muy rápido en comparación con los subprocesos del espacio del usuario.
Si hablamos de Linux, los subprocesos del kernel están optimizados hasta tal punto que se consideran mejores que los subprocesos del espacio del usuario y se utilizan principalmente en todos los escenarios, excepto donde el requisito principal es la multitarea cooperativa.
Problema con subprocesos
Hay algunos problemas importantes que surgen al usar subprocesos:
- Muchos sistemas operativos no implementan subprocesos como procesos, sino que ven los subprocesos como parte del proceso principal. En este caso, ¿qué sucedería si un subproceso llama a fork() o, peor aún, qué sucedería si un subproceso ejecuta un nuevo binario? Estos escenarios pueden tener consecuencias peligrosas, por ejemplo, en el problema posterior, todo el proceso principal podría reemplazarse con el espacio de direcciones del binario recién ejecutado. Esto no es en absoluto deseado. Linux, que es una queja de POSIX, se asegura de que llamar a un fork() duplique solo el subproceso que ha llamado a la función fork(), mientras que un ejecutor de cualquiera de los subprocesos detendría todos los subprocesos en el proceso principal.
- Otro problema que puede surgir son los problemas de concurrencia. Dado que los subprocesos comparten todos los segmentos (excepto el segmento de la pila) y el planificador puede adelantarse en cualquier etapa, cualquier variable global o estructura de datos que pueda dejarse en un estado inconsistente por la preferencia de un subproceso podría causar problemas graves cuando la siguiente prioridad alta thread ejecuta la misma función y usa las mismas variables o estructuras de datos.
Para el problema 1 mencionado anteriormente, todo lo que podemos decir es que es un problema de diseño y el diseño de las aplicaciones debe hacerse de manera que surjan menos problemas de este tipo.
Para el problema 2 mencionado anteriormente, al usar mecanismos de bloqueo, el programador puede bloquear una parte del código dentro de una función, de modo que incluso si ocurre un cambio de contexto (cuando la variable global de la función y las estructuras de datos estaban en un estado inconsistente), el siguiente hilo tampoco puede ejecute el mismo código hasta que el bloque de código bloqueado dentro de la función sea desbloqueado por el subproceso anterior (o el subproceso que lo adquirió).