2012-04-10 7 views
5

Tengo algunas dudas con respecto a la concurrencia de subprocesos posix en la máquina multiprocesador. He encontrado preguntas similares en SO al respecto, pero no encontré una respuesta concluyente.Concurrencia de subprocesos posix en la máquina multiprocesador

Debajo está mi comprensión. Quiero saber si estoy en lo correcto.

  1. hilos POSIX son hilos a nivel de usuario y el núcleo no es consciente de ello.

  2. El programador 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.

  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 pueden ejecutarse al mismo tiempo.

Háganme saber si mi entendimiento es el correcto.

Gracias ...

+2

Todos los puntos son incorrectos, como estoy seguro que los otros críticos que opinan

Respuesta

9

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.

+0

Para roscas de espacio de usuario, leí que cambio de contexto no se da en el espacio del núcleo. ¿Es eso correcto? – hackrock

+0

Hay implementaciones de subprocesos @rocky que hacen el cambio de contexto en el espacio de usuario, pero no un pthread estándar en Linux. La conmutación de contexto puede involucrar el registro de volcado, manipulación de pila, limpieza de la memoria caché, etc. y muchas de estas funciones no se pueden realizar en el área de usuario. – Gray

5

POSIX no especifica cómo se programan los hilos creados con pthread_create en los núcleos del procesador. Esto depende de la implementación.

Sin embargo, esperaría lo siguiente en una aplicación de calidad, y este es el caso para las versiones actuales de Linux:

  • Los hilos son los hilos del núcleo completo, y programadas por el núcleo
  • Hilos de la el mismo proceso se puede ejecutar simultáneamente en procesadores separados

es decir, las 3 declaraciones numeradas son incorrectas con las implementaciones actuales de Linux, pero en teoría podrían ser ciertas para otra implementación que también se ajuste a POSIX.

+0

No veo otro uso de tener subprocesos de espacio de usuario aparte de evitar cualquier exceso involucrado en el cambio de contexto. ¿Existe alguna biblioteca de subprocesos de espacio de usuario o la biblioteca de subprocesos de Posix proporciona algún mecanismo para crear subprocesos en el espacio de usuario al pasar los atributos durante la creación de subprocesos? – hackrock

0

La mayoría de las implementaciones POSIX utilizan la compatibilidad con el sistema operativo para proporcionar funcionalidad de subprocesos: completan las llamadas al sistema necesarias para administrar los subprocesos. Como tal, el comportamiento de los hilos re. la programación, etc. depende del sistema operativo subyacente.

Así, en la mayoría OS moderna:

  1. un proceso con los hilos POSIX no es diferente a la del núcleo que cualquier otro proceso con múltiples hilos.

  2. El planificador del núcleo distribuye los hilos, no los procesos. Un 'proceso' se considera a menudo como un constructo de nivel superior que tiene permisos de código, administración de memoria, cuotas, auditoría y seguridad, pero no ejecución. Un proceso no puede hacer nada a menos que un hilo ejecute su código, que es la razón por la cual, cuando se crea un proceso, se crea un 'hilo principal' al mismo tiempo, de lo contrario no se ejecutaría nada. El algoritmo de programación del sistema operativo puede usar el proceso que ejecuta el hilo como uno de los parámetros para decidir qué conjunto de hilos listos ejecutar a continuación - es más barato intercambiar un hilo por uno del mismo proceso - pero no tiene por qué hacerlo.

    Cortar el tiempo de CPU proporcionado por el kernel entre los subprocesos ejecutables es un efecto secundario de la interrupción del temporizador del sistema operativo cuando hay más hilos listos que núcleos para ejecutarlos.Cualquier máquina que regularmente tenga que recurrir a (¡uf! - Odio el término), 'time slicing' debería considerarse como sobrecargada y debería tener más CPU o menos trabajo. En el mejor de los casos, los subprocesos solo estarán listos cuando lo señale otro subproceso o un controlador IO, no porque la interrupción del temporizador del sistema operativo haya decidido ejecutarlo en lugar de otro subproceso que aún podría estar haciendo un trabajo útil.

  3. Simplemente se pueden ejecutar al mismo tiempo. Si dos hilos están listos y hay dos núcleos, los hilos se envían a los dos núcleos. No importa si son del mismo proceso o no.

Cuestiones relacionadas