Imagine que tengo dos (tres, cuatro, lo que sea) tareas que tienen que ejecutarse en paralelo. Ahora, la manera más fácil de hacer esto sería crear hilos separados y olvidarse de eso. Pero en una vieja y simple CPU de un solo núcleo eso significaría una gran cantidad de cambio de contexto, y todos sabemos que el cambio de contexto es grande, malo, lento y, en general, simplemente Evil. Debe evitarse, ¿verdad?¿Qué tan caro es un cambio de contexto? ¿Es mejor implementar un cambio de tarea manual que confiar en los hilos del sistema operativo?
En ese sentido, si estoy escribiendo el software desde cero todos modos, podría ir más allá y poner en práctica mi propia tarea de conmutación. Divida cada tarea en partes, guarde el estado entre ellas, y luego cambie entre ellas dentro de un solo hilo. O bien, si detecto que hay múltiples núcleos de CPU, podría asignar cada tarea a un hilo por separado y todo estaría bien.
La segunda solución tiene la ventaja de adaptarse al número de núcleos de CPU disponibles, pero va a la tarea-interruptor manual realmente ser más rápido que el que está en el núcleo del sistema operativo? Especialmente si estoy tratando de hacer todo genérico con un TaskManager y un ITask, etc.
Aclaración: Soy un desarrollador de Windows, por lo que estoy interesado principalmente en la respuesta para este sistema operativo, pero sería muy interesante conocer otros sistemas operativos también. Cuando escriba su respuesta, indique para qué sistema operativo es.
Más aclaración: Bien, entonces esto no está en el contexto de una aplicación en particular. En realidad es una pregunta general, el resultado de mis reflexiones sobre la escalabilidad. Si quiero que mi aplicación escale y utilice de manera efectiva las futuras CPU (e incluso las diferentes CPU de hoy en día), debo hacerlo con subprocesos múltiples. Pero, ¿cuántos hilos? Si hago un número constante de subprocesos, entonces el programa funcionará de manera subóptima en todas las CPU que no tengan la misma cantidad de núcleos.
Lo ideal sería que el número de hilos sería determinado en tiempo de ejecución, pero pocas son las tareas que realmente se pueden dividir en el número arbitrario de piezas en tiempo de ejecución. Sin embargo, muchas tareas se pueden dividir en una cantidad bastante grande y constante de hilos en el momento del diseño. Entonces, por ejemplo, si mi programa pudiera engendrar 32 hilos, ya utilizaría todos los núcleos de hasta 32 núcleos de CPU, lo cual está bastante lejos en el futuro (creo). Pero en una CPU simple de un solo núcleo o doble núcleo significaría MUCHO cambio de contexto, lo que ralentizaría las cosas.
Por lo tanto, mi idea sobre la conmutación manual de tareas. De esta forma, uno podría hacer 32 hilos "virtuales" que se mapearían con tantos hilos reales como sea óptimo, y el "cambio de contexto" se haría manualmente. La pregunta es: ¿la sobrecarga de mi manual "cambio de contexto" sería menor que la del cambio de contexto del sistema operativo?
Naturalmente, todo esto se aplica a los procesos que están vinculados a la CPU, como los juegos. Para su aplicación CRUD corriente, esto tiene poco valor. Tal aplicación se hace mejor con un hilo (como máximo dos).
¿Qué sistema operativo le interesa? Esto varía * ampliamente * en todos los sistemas operativos. –
Básicamente soy un programador de Windows, pero sería interesante conocer otros sistemas operativos también. Traté de hacer la pregunta bastante agnóstica para el sistema operativo. –
@Vilx Esta pregunta, por su propia naturaleza, nunca puede ser ajena al sistema operativo. – Cromulent