Cuando inicia múltiples subprocesos en un procesador multinúcleo, ¿se garantiza que sean procesados ​​por diferentes núcleos?

24

Tengo un procesador Pentium core i5, que tiene 4 núcleos. Si hago esto en un programa de consola C #

var t1 = new Thread(Thread1);
var t2 = new Thread(Thread2);
t1.Start();
t2.Start();

¿Se garantiza que los subprocesos t1 y t2 se ejecuten en núcleos separados?

cpu c# threading desarrollador747
fuente
1
Suponiendo que el tiempo de ejecución de C # utiliza llamadas del sistema nativo equivalentes para generar otro subproceso (y, por lo tanto, es realmente paralelo; este no es el caso para todo, como el infame Bloqueo de intérprete global de CPython ), esto dependería únicamente del proceso / programador de tareas del sistema operativo . Sin embargo, en general, el código es verdaderamente seguro para subprocesos si asume eso t1y t2se ejecuta en diferentes momentos en un orden arbitrario (por ejemplo, es posible que t2comience antes t1 en algunos modelos).
Avance el
2
No sabía que había procesadores Pentium i5. Tal vez te referías a Core i5? Difícil. Lo sé: D
JosephGarrone

Respuestas:

18

No puede garantizar en .Net que dos Threads se ejecuten en dos núcleos separados. De hecho, tampoco puede garantizar que Threadse ejecutará en un solo núcleo (!) .

Esto se debe a que los subprocesos administrados no son lo mismo que los subprocesos del sistema operativo : un solo subproceso administrado puede usar múltiples subprocesos del sistema operativo para admitirlo. En C #, solo trata directamente con Threads administrados (al menos, sin recurrir a p / invoke para llamar a las funciones de subprocesos de WinAPI, lo que nunca debe hacer) .

Sin embargo, los planificadores de subprocesos .Net y Windows son muy buenos en lo que hacen: no ejecutarían dos subprocesos en un solo núcleo, mientras que un segundo núcleo está completamente inactivo. Por lo tanto, en general, no necesita preocuparse por eso.

BlueRaja - Danny Pflughoeft
fuente
En la práctica, .Net Threads son hebras de SO. Pero esa no es la razón por la cual no hay garantía de que un solo hilo siempre se ejecute en el mismo núcleo.
svick
2
@svick: En la práctica, en x86 , eso es cierto. Sin embargo, el estándar establece explícitamente que no puede confiar en este comportamiento, por lo que podría cambiar en el futuro. De hecho, es no cierto en otras versiones de .NET CLR, como la Xbox 360 de.
BlueRaja - Danny Pflughoeft
@BlueRaja: la pregunta es específica acerca de qué versión del CLR estamos hablando. Puede garantizar que algo existirá en dos núcleos separados mediante el uso de subprocesos asíncronos porque significaría que suceden de forma asíncrona entre sí. El código de ejemplo actual es una llamada de sincronización técnicamente. Por supuesto, el sistema operativo decide qué núcleos se utilizarán.
Ramhound
@Ramhound "Puede garantizar que algo existirá en dos núcleos separados mediante el uso de hilos asincrónicos" , eso es falso. La asyncpalabra clave (que es de lo que supongo que está hablando, ya que "hilos asíncronos" es redundante) es simplemente azúcar sintáctica para usar un BackgroundWorkerhilo, que es como cualquier otro hilo .Net; no puede garantizar si se ejecutará en un núcleo separado o no.
BlueRaja - Danny Pflughoeft
@BlueRaja: si se iniciaran dos subprocesos asíncronos, ambos se ejecutarían al mismo tiempo siempre que hubiera 2 núcleos de CPU. Si solo hubiera uno, entonces el sistema operativo programaría cuándo cada subproceso tendría prioridad y se ejecutaría, y su situación típica de agitación de un solo subproceso ocurriría. Así fue como me enseñaron cómo una CPU maneja subprocesos múltiples.
Ramhound
15

No, el sistema operativo y la CPU decidirán qué ejecutar y cuándo. en el ejemplo simple que ha mostrado, excluyendo otras tareas, sí, esas probablemente se ejecutarían en paralelo en núcleos separados, pero rara vez hay una garantía de que ese sea el caso.

Puede usar la afinidad de subproceso para intentar tomar cierto control sobre la asignación de un núcleo a un subproceso determinado.

También considere las prioridades de programación para apilar el mazo en términos de qué hilos deben ser completamente paralelos y cuáles pueden esperar.

Frank Thomas
fuente
1
También quiero agregar que con las tecnologías de virtualización hay otra capa entre su programa y el hardware. Lo que el sistema operativo presenta a la aplicación puede no ser físicamente preciso.
Keltari
1
Esas son funciones de WinAPI para subprocesos del sistema operativo, no para subprocesos administrados. Nunca deberían llamarse desde C #, ya que podrían interferir severamente con el programador de hilos .Net.
BlueRaja - Danny Pflughoeft