multithreading - resueltos - procesos hijos e hilos
Concurrencia: Procesos vs Hilos (4)
¿Cuáles son las principales ventajas de utilizar un modelo de concurrencia basado en procesos sobre uno basado en hilos y en qué contextos es el último apropiado?
En primer lugar, los procesos difieren de los hilos principalmente en la forma en que se maneja su memoria:
Process = n*Thread + memory region (n>=1)
Los procesos tienen su propia memoria aislada. Los procesos pueden tener múltiples hilos.
Los procesos están aislados entre sí en el nivel del sistema operativo. Los hilos comparten su memoria con sus compañeros en el proceso. (Esto a menudo es indeseable. Hay bibliotecas y métodos para remediar esto, pero eso suele ser una capa artificial sobre los hilos del sistema operativo).
La cosa de la memoria es el factor de discernimiento más importante, ya que tiene ciertas implicaciones:
- El intercambio de datos entre procesos es más lento que entre hilos. Romper el aislamiento del proceso siempre requiere una participación de llamadas al kernel y reasignación de memoria.
- Los hilos son más livianos que los procesos. El sistema operativo debe asignar recursos y administrar la memoria para cada proceso.
- El uso de procesos le brinda aislamiento y sincronización de memoria. Los problemas comunes con el acceso a la memoria compartida entre hilos no le conciernen. Ya que debe hacer un esfuerzo especial para compartir datos entre procesos, lo más probable es que se sincronice automáticamente con eso.
El uso de procesos le proporciona una buena (o última) encapsulación. Como la comunicación entre procesos requiere un esfuerzo especial, se verá forzado a definir una interfaz limpia. Es una buena idea separar ciertas partes de su aplicación del ejecutable principal. Tal vez puedas dividir dependencias así. por ejemplo, Process_RobotAi <-> Process_RobotControl La IA tendrá dependencias muy diferentes en comparación con el componente de control. La interfaz puede ser simple: Process_RobotAI --DriveXY--> Process_RobotControl . Tal vez cambias la plataforma del robot. Solo tiene que implementar un nuevo ejecutable de RobotControl con esa interfaz simple. No tiene que tocar o incluso recompilar nada en su componente AI.
También, por las mismas razones, acelerará la compilación en la mayoría de los casos.
Editar: Solo para completar, agregaré desvergonzadamente lo que me han recordado los demás: un proceso de bloqueo no bloquea (necesariamente) toda la aplicación.
En general:
- Desea crear algo altamente concurrente o sincrónico, como un algoritmo con n >> 1 instancias ejecutándose en paralelo y compartiendo datos, use subprocesos.
- Tener un sistema con múltiples componentes que no necesitan compartir datos o algoritmos, ni intercambian datos con demasiada frecuencia, usan procesos. Si utiliza una biblioteca RPC para la comunicación entre procesos, obtendrá una solución distribuible de red sin costo adicional.
1 y 2 son los escenarios extremos y obvios, todo en el medio debe decidirse individualmente.
Para un buen (o asombroso) ejemplo de un sistema que usa IPC / RPC en gran medida, eche un vistazo a ros .
La desventaja de utilizar un modelo basado en procesos es que será más lento. Tendrá que copiar datos entre las partes simultáneas de su programa.
La desventaja de utilizar un modelo basado en subprocesos es que probablemente se equivocará. Puede sonar malo, pero es verdad-- muéstrame el código basado en hilos y te mostraré un error. He encontrado errores en el código del hilo que se ha ejecutado "correctamente" durante 10 años.
Las ventajas de usar un modelo basado en procesos son numerosas. La separación te obliga a pensar en términos de protocolos y patrones de comunicación formales, lo que significa que es mucho más probable que lo hagas bien. Los procesos que se comunican entre sí son más fáciles de escalar en múltiples máquinas. Múltiples procesos simultáneos permiten que un proceso se bloquee sin necesariamente colapsar los otros.
La ventaja de utilizar un modelo basado en subprocesos es que es rápido.
Puede ser obvio cuál de los dos prefiero, pero en caso de que no lo sea: procesos, todos los días de la semana y dos veces el domingo. Los hilos son demasiado difíciles: nunca he conocido a nadie que pudiera escribir el código correcto de múltiples hilos; aquellos que dicen ser capaces de generalmente no saben lo suficiente sobre el espacio todavía.
En este caso, los procesos son más independientes entre sí, mientras que Threads comparte algunos recursos, por ejemplo, la memoria. Pero en un caso general, los hilos son más livianos que los procesos.
Los procesos Erlang no son lo mismo que los Procesos OS. Los procesos Erlang son muy livianos y Erlang puede tener muchos Procesos Erlang dentro del mismo subproceso OS. Ver técnicamente ¿por qué los procesos en Erlang son más eficientes que los hilos del sistema operativo?
La tolerancia a fallas y la escalabilidad son las principales ventajas de usar Procesos vs. Hilos.
Un sistema que se basa en la memoria compartida u otro tipo de tecnología que solo está disponible cuando se utilizan subprocesos, será inútil cuando quiera ejecutar el sistema en varias máquinas. Tarde o temprano necesitarás comunicarte entre diferentes procesos.
Cuando utiliza procesos, se ve forzado a tratar con la comunicación a través de mensajes, por ejemplo, esta es la forma en que Erlang maneja la comunicación. Los datos no se comparten, por lo que no existe riesgo de corrupción de datos.
Otra ventaja de los procesos es que pueden bloquearse y puede sentirse relativamente seguro sabiendo que puede reiniciarlos (incluso a través de los hosts de la red). Sin embargo, si un hilo falla, puede bloquearse todo el proceso, lo que puede hacer que baje toda la aplicación. Para ilustrarlo: si un proceso de Erlang falla, solo perderá esa llamada telefónica, o esa carga de correo electrónico, etc. No es la aplicación completa.
Al decir todo esto, los procesos de sistema operativo también tienen muchos inconvenientes que pueden dificultar su uso, como el hecho de que demora un proceso nuevo. Sin embargo, Erlang tiene su propia noción de procesos, que son extremadamente livianos.
Dicho esto, esta discusión es realmente un tema de investigación. Si desea entrar en más detalles, puede dar el artículo de Joe Armstrong sobre sistemas tolerantes a fallas] 1 una lectura, explica mucho sobre Erlang y la filosofía que lo impulsa.