Un subproceso es "liviano" porque la mayor parte de la sobrecarga ya se ha realizado mediante la creación de su proceso.¿Por qué los hilos se llaman procesos livianos?
Lo encontré en uno de los tutoriales.
¿Puede alguien explicar qué significa exactamente?
La afirmación de que los hilos son "livianos" es, dependiendo de la plataforma, no necesariamente confiable.
Una cadena de sistema operativo debe ser compatible con la ejecución de código nativo, p. escrito en C. Así que tiene que proporcionar una pila de tamaño decente, generalmente medida en megabytes. Por lo tanto, si inició 1000 subprocesos (quizás en un intento de admitir 1000 conexiones simultáneas a su servidor), tendría un requerimiento de memoria de 1 GB en su proceso antes de siquiera comenzar a hacer un trabajo real.
Esto es un problema real en servidores altamente escalables, por lo que no usan subprocesos como si fueran ligeros en absoluto. Ellos los tratan como recursos pesados. En su lugar, podrían crear un número limitado de subprocesos en un grupo y dejar que tomen elementos de trabajo de una cola.
Como esto significa que los hilos son duraderos y de pequeño tamaño, podría ser mejor usar procesos en su lugar. De esta forma, obtiene el aislamiento del espacio de direcciones y no hay realmente un problema con quedarse sin recursos.
En resumen: desconfíe de las afirmaciones de "comercialización" realizadas en nombre de los hilos. El procesamiento en paralelo es excelente (cada vez será más necesario), pero los hilos son solo una forma de lograrlo.
+1 Spot on - no podría haberlo mejorado – zebrabox
Me encanta el resumen. Tiendo a preferir el uso de múltiples procesos de subproceso único, y lo * odio * cuando los fan-boyers de subprocesos múltiples me acusan de no aprovechar el paralelismo fácil de múltiples núcleos porque no asimilan la idea de procesos múltiples. –
Gracias. Hay muchas razones por las cuales el proceso a veces puede ser mejor que los hilos. ¡Una que me sorprendió es que podrías obtener un impulso de rendimiento gratis! La razón es que los procesos separados tienen montones de memoria C separados. En una biblioteca estándar segura para subprocesos, todas las llamadas 'malloc' /' free' tienen que estar sincronizadas, lo que podría significar un montón de bloqueo dependiendo de su uso de memoria. He visto una aplicación que usa la parada de subprocesos en 4 núcleos, pero cuando se cambia a procesos separados, se escalaría a 8 (y probablemente más, no tenía más núcleos para probar). Cuanta menos memoria comparta, menos tendrá que sincronizar. –
La creación de procesos es "costosa", ya que tiene que configurar un nuevo espacio de memoria virtual para el proceso con su propio espacio de direcciones. "costoso" significa que requiere mucho tiempo de CPU.
No es necesario que los hilos de rosca hagan esto, simplemente cambie algunos punteros, por lo que es mucho más "barato" que crear un proceso. La razón por la cual los hilos no necesitan esto es porque se ejecutan en el espacio de direcciones y en la memoria virtual del proceso principal.
Cada proceso debe tener al menos un hilo. Entonces, si lo piensas, crear un proceso significa crear el proceso Y crear un hilo. Obviamente, crear solo un hilo tomará menos tiempo y funcionará en la computadora.
Además, los hilos son "livianos" porque los hilos pueden interactuar sin necesidad de comunicación entre procesos. Cambiar de subprocesos es "más barato" que cambiar de proceso (una vez más, basta con mover algunos punteros). Y la comunicación entre procesos requiere una comunicación más costosa que los hilos.
Los subprocesos dentro de un proceso comparten el mismo espacio de memoria virtual, pero cada uno tiene una pila separada, y posiblemente "almacenamiento local de subprocesos" si está implementado. Son ligero porque un cambio de contexto es simplemente un caso de cambiar el puntero de la pila y el contador de programa y restaurar otros registros, cuando un proceso cambio de contexto implica también cambiar el contexto MMU.
Además, la comunicación entre subprocesos dentro de un proceso es liviana porque comparten un espacio de direcciones.
No es liviano si tiene un sistema mulit-core que necesita sincronizar datos entre las cachés L1 para hilos múltiples, de hecho eso es cualquier cosa menos liviano – zebrabox
@zebrabox: Sin dudas cierto. Como siempre, dichos términos se vuelven irrelevantes a lo largo del tiempo. La mayor parte de mi trabajo se basa en sistemas embebidos de un solo núcleo con kernels RTOS, por lo que rara vez se han presentado complejidades, todo es un hilo, incluso cuando están protegidas por una MMU (contradiciendo lo que dije antes). – Clifford
Sí, sé de dónde vienes. Obviamente, no es un problema en una máquina de núcleo único, especialmente si tiene acceso a un par de hilos de hardware :) – zebrabox
proceso:
hilo:
Un proceso contiene uno o más hilos en el mismo y una rosca pueden hacer cualquier cosa que un proceso puede hacer. También los hilos dentro de un proceso comparten el mismo espacio de direcciones debido a que el costo de comunicación entre hilos es bajo ya que está utilizando la misma sección de códigos, sección de datos y recursos del SO, por lo que todas estas características del hilo lo convierten en un "proceso liviano".
Manteniendo el binging para la "creación de procesos" y su sistema operativo, y verá la cantidad de sobrecarga para crear un proceso. –
@No reembolsos Sin devoluciones: Y encontrará que difiere considerablemente entre los sistemas operativos. –
@No reembolsos No Devoluciones: ¿qué se escucha por casualidad entre la sincronización de caché entre subprocesos en una máquina multinúcleo o la sobrecarga de cambio de contexto y guardando el estado de pila y el conjunto de registros? – zebrabox