.NET movimiento de hilos entre los núcleos

Question

Pregunta de seguimiento desde Multi-core usage, threads, thread-pools.

¿Los hilos se mueven de un núcleo a otro durante su vida útil?

Por supuesto. Imagine que tiene tres hilos ejecutándose en un sistema dualcore. Muéstreme un calendario justo que no involucre el movimiento regular de los hilos entre los núcleos.

Esta es mi primera vez en este sitio, por lo que no tuve suficiente reputación para hacer un comentario, supongo. Decidí hacer una nueva pregunta sobre la que quería comentar.

¿Cuál es el proceso de selección de un núcleo para mover un hilo? ¿Es que el planificador tiene una lista de hilos que necesitan tiempo de procesamiento y cuando uno termina, coloca otro?

También me preguntaba si hay una referencia para la afirmación de que los hilos se mueven entre los núcleos en absoluto. ¿O solo se considera "conocimiento común"?

Gracias!

Answer 1

No es que el hilo esté viviendo en un núcleo particular y que es un proceso de moviendo a otro.

El sistema operativo simplemente tiene una lista de subprocesos (y/o procesos) que están listos para ejecutarse y los distribuirá en cualquier core/cpu que esté disponible.

Dicho esto, cualquier programador inteligente tratará de programar el hilo en el mismo núcleo tanto como sea posible - simplemente para aumentar el rendimiento (datos es más probable que sea en la que el núcleo de caché, etc.)

Answer 2

MSDN tiene algunos artículos que probablemente ayudarían a aclarar algunas cosas: Scheduling Priorities y Multiple Processors.

Extracto (Programación de Prioridades):

están programadas subprocesos para ejecutar basa en su prioridad de planificación. A cada subproceso se le asigna una prioridad de programación. Los niveles de prioridad van desde cero (prioridad más baja) hasta 31 (prioridad más alta ). Solo el subproceso sin página puede tener una prioridad cero. (El hilo página cero es un subproceso del sistema responsable de la reducción a cero cualquiera de las páginas gratuitas cuando no hay otros hilos que necesitan para funcionar.)

El sistema trata todas las discusiones con la misma prioridad que iguales. El sistema asigna segmentos de tiempo en una forma round-robin a todos los hilos con la prioridad más alta . Si ninguno de estos subprocesos está listo para ejecutarse, el sistema asigna intervalos de tiempo en todos los subprocesos con la siguiente prioridad . Si una mayor prioridad hilo esté disponible para funcionar, el sistema deja de ejecutar el hilo de menor prioridad (sin permitiendo que se termine de usar su tiempo de rebanada), y asigna un tiempo completo rebanada a la más alta prioridad hilo.

Y en lo que respecta a múltiples procesadores:

equipos con varios procesadores están diseñados típicamente para una de las dos arquitecturas: acceso a la memoria no uniforme (NUMA) o multiprocesamiento simétrico (SMP).

En una computadora NUMA, cada procesador está más cerca de algunas partes de la memoria que otras, lo que hace que el acceso a la memoria sea más rápido para algunas partes de la memoria que otras partes. Bajo el modelo NUMA, el sistema intenta programar subprocesos en procesadores que están cerca de la memoria que se está utilizando. Para obtener más información acerca de NUMA, vea Soporte de NUMA.

En una computadora SMP, dos o más procesadores o núcleos idénticos se conectan a una sola memoria principal compartida. Bajo el modelo SMP, cualquier hilo se puede asignar a cualquier procesador. Por lo tanto, programar subprocesos en una computadora SMP es similar a programar subprocesos en una computadora con un solo procesador. Sin embargo, el programador tiene un grupo de procesadores, por lo que puede programar los hilos para que se ejecuten al mismo tiempo. La programación todavía está determinada por la prioridad de subproceso, pero puede influirse configurando la afinidad de subprocesos y el procesador ideal de subprocesos, como se explica en este tema.

Answer 3

Windows proporciona la API para configurar thread affinity (es decir, para configurar las CPU a las que se debe programar este subproceso). No habrá necesidad de tal API si thread siempre se ejecuta en un núcleo.

Answer 4

Es Es como si el programador tuviera una lista de hilos que necesitaran tiempo de procesamiento y cuando uno termina de poner adentro?

Casi. Lo que usted describe se llama cooperative multi-tasking, donde se espera que los subprocesos cedan regularmente la ejecución al planificador (por ejemplo, viviendo solo por un tiempo breve, o llamando regularmente al Thread.Current.Sleep(0)). No es así como funciona un sistema operativo moderno para el consumidor, ya que un hilo poco cooperativo puede encerrar a la CPU en dicho sistema.

Lo que sucede en cambio es que a intervalos de tiempo regulares, se produce un context switch. El hilo en ejecución, le guste o no, está suspendido. Esto implica almacenar una instantánea del estado de los registros de la CPU en la memoria. El programador del kernel tiene la oportunidad de ejecutar y reevaluar la situación, y puede decidir dejar que otro subproceso se ejecute por un tiempo. De esta forma, se asignan segmentos de tiempo de CPU (medidos en milisegundos o menos) a los diferentes subprocesos. Esto se llama pre-emptive multitasking.

Cuando un sistema tiene más de una CPU o múltiples núcleos de CPU, sucede lo mismo con cada núcleo. La ejecución en cada núcleo se suspende regularmente, y el planificador decide qué subproceso ejecutar en él a continuación. Como cada núcleo de CPU tiene los mismos registros, el planificador puede mover un hilo entre núcleos mientras intenta asignar porciones de tiempo.