Desde que marcó su pregunta con la etiqueta "Linux" Voy a responder de acuerdo a la aplicación pthreads estándar en Linux. Si está hablando de "green" threads, que están programados en la VM/nivel de idioma en lugar del sistema operativo, entonces sus respuestas son en su mayoría correctas. Pero mis comentarios a continuación están en Linux pthreads.
1) Los subprocesos de Posix son subprocesos de nivel de usuario y el kernel no tiene conocimiento de ello.
No, esto ciertamente no es correcto. Las bibliotecas kernel y pthreads de Linux trabajan juntas para administrar los hilos. El kernel realiza el cambio de contexto, la programación, la gestión de memoria, la gestión de la memoria caché, etc. Hay otra administración realizada en el nivel de usuario, pero sin él kernel, se perderá gran parte del poder de los pthreads.
2) El planificador de Kernel tratará el Proceso (con todos sus hilos) como una sola entidad para la programación. Es la biblioteca de hilos la que a su vez elige qué hilo ejecutar. Puede dividir el tiempo de CPU proporcionado por el kernel entre los hilos ejecutables.
No, el kernel trata cada proceso de hilo como una entidad. Tiene sus propias reglas sobre la segmentación temporal que tienen en cuenta los procesos (y las prioridades del proceso), pero cada subproceso es una entidad programable.
3) Los hilos de usuario pueden ejecutarse en diferentes núcleos de la CPU. es decir, deje que los subprocesos T1 & T2 se creen mediante un Proceso (T), luego T1 se puede ejecutar en Cpu1 y T2 se puede ejecutar en Cpu2 PERO no se pueden ejecutar al mismo tiempo. Se espera
Nº concurrente de ejecución de programas multihilo. Es por eso que la sincronización y los mutex son tan importantes y por qué los programadores soportan la complejidad de la programación multiproceso.
Una forma de probar esto a que es mirar a la salida del ps
con -L
opción para mostrar los temas asociados. ps
generalmente envuelve múltiples procesos de rosca en una sola línea, pero con -L
se puede ver que el núcleo tiene una separada virtuales proceso de identificación para cada hilo:
ps -ef | grep 20587
foo 20587 1 1 Apr09 ? 00:16:39 java -server -Xmx1536m ...
frente
ps -eLf | grep 20587
foo 20587 1 20587 0 641 Apr09 ? 00:00:00 java -server -Xmx1536m ...
foo 20587 1 20588 0 641 Apr09 ? 00:00:30 java -server -Xmx1536m ...
foo 20587 1 20589 0 641 Apr09 ? 00:00:03 java -server -Xmx1536m ...
...
No estoy seguro de si hilos de Linux siguen haciendo esto, pero históricamente pthreads utilizan la llamada clone(2)
sistema para crear otra copia de sí mismo hilo:
a diferencia de tenedor (2), TH Estas llamadas permiten que el proceso secundario comparta partes de su contexto de ejecución con el proceso de llamada, como el espacio de memoria, la tabla de descriptores de archivos y la tabla de manejadores de señales.
Esto es diferente de fork(2)
que se utiliza cuando se crea otro proceso completo.
Todos los puntos son incorrectos, como estoy seguro que los otros críticos que opinan –