multithreading - thread - ¿Cómo recupera el programador del sistema operativo la CPU?
que es multithreading en programacion (3)
Recientemente comencé a aprender cómo funciona la CPU y el sistema operativo, y estoy un poco confundido sobre el funcionamiento de una máquina de una sola CPU con un sistema operativo que proporciona tareas múltiples.
Como tal, suponiendo que mi máquina tenga una única CPU, esto significaría que, en un momento dado, solo podría estar ejecutándose un proceso.
Ahora, solo puedo suponer que el programador utilizado por el sistema operativo para controlar el acceso al precioso tiempo de CPU también es un proceso.
Por lo tanto, en esta máquina, el proceso del usuario o el proceso del sistema de programación se está ejecutando en cualquier punto dado en el tiempo, pero no en ambos.
Así que aquí hay una pregunta:
Una vez que el programador cede el control de la CPU a otro proceso, ¿cómo puede recuperar el tiempo de CPU para ejecutarse de nuevo para hacer su trabajo de programación? Quiero decir, si algún proceso dado actualmente en ejecución no renuncia (cede) a la CPU, ¿cómo podría el planificador funcionar nunca más y garantizar una multitarea adecuada?
Hasta ahora, he estado pensando, bueno, si el proceso de usuario solicita una operación de E / S a través de una llamada al sistema, entonces en la llamada al sistema podríamos asegurar que el programador tenga asignado nuevamente tiempo de CPU. Pero ni siquiera estoy seguro de si esto funciona de esta manera.
Por otro lado, si el proceso del usuario en cuestión estaba intrínsecamente vinculado a la CPU, entonces, desde este punto de vista, podría ejecutarse para siempre, sin dejar que otros procesos, ni siquiera el planificador se ejecuten nuevamente.
Suponiendo una programación por divisiones de tiempo, no tengo idea de cómo el planificador podría dividir el tiempo para la ejecución de otro proceso, cuando ni siquiera se está ejecutando.
Realmente agradecería cualquier idea o referencia que pueda proporcionar al respecto.
El sistema operativo configura un temporizador de hardware (temporizador de intervalo programable o PIT) que genera una interrupción cada N milisegundos. Esa interrupción se entrega al kernel y el código de usuario se interrumpe.
Funciona como cualquier otra interrupción de hardware. Por ejemplo, su disco forzará un cambio al kernel cuando haya completado un IO.
Google ''interrumpe''. Las interrupciones están en el centro de los núcleos preventivos multihilo, como Linux / Windows. Sin interrupciones, el sistema operativo nunca hará nada.
Mientras investiga / aprende, trate de ignorar cualquier explicación que mencione ''interrupción por temporizador'', ''round-robin'' y ''time-slice'', ''quantum'' en el primer párrafo - son peligrosamente engañosas, si no realmente incorrectas.
Las interrupciones, en términos de SO, vienen en dos sabores:
Interrupciones de hardware: las iniciadas por una señal de hardware real de un dispositivo periférico. Esto puede suceder en (casi) cualquier momento y cambiar la ejecución de cualquier cadena que se esté ejecutando al código en un controlador.
Interrupciones de software: aquellas iniciadas por las llamadas del sistema operativo desde los hilos actualmente en ejecución.
Cualquiera de las interrupciones puede solicitar al planificador que cree subprocesos que esperaban estar listos / en ejecución o que hicieran que los subprocesos que estaban esperando / ejecutando fueran reemplazados.
LOS INTERRUPTORES MÁS IMPORTANTES SON LOS INTERRUPTORES DE HARDWARE DE CONDUCTORES PERIFÉRICOS, aquellos que preparan hilos que esperaban en IO de discos, tarjetas NIC, ratones, teclados, USB, etc. La razón primordial para usar kernels preventivos, y todos los problemas de bloqueo, sincronización, señalización, etc., es que tales sistemas tienen MUY BUEN RENDIMIENTO IO PORQUE LOS PERIFÉRICOS DE HARDWARE PUEDEN HACER RÁPIDAMENTE HILOS HERRAMIENTAS QUE FUNCIONAN QUE ESPERA INFORMACIÓN DE ESE HARDWARE, SIN ALGUNA LATENCIA RESULTANTE DE HILOS QUE NO RINDEN O ESPERA UN PERIÓDICO RESORTE DE TEMPORIZADOR.
La interrupción del temporizador de hardware que causa la ejecución periódica de la programación es importante porque muchas llamadas al sistema tienen tiempos de espera en caso de que, por ejemplo, una respuesta de un periférico tarde más de lo debido.
En los sistemas multinúcleo, el sistema operativo tiene un controlador interprocesador que puede causar una interrupción de hardware en otros núcleos, lo que permite que el sistema operativo interrumpa / programe / envíe hilos a múltiples núcleos.
En cajas seriamente sobrecargadas, o aquellas que ejecutan aplicaciones intensivas en CPU, (una pequeña minoría), el sistema operativo puede usar las interrupciones periódicas del temporizador y la programación resultante para recorrer un conjunto de hilos listos que es mayor que el número de núcleos disponibles y así permitir a cada una parte de los recursos de CPU disponibles. En la mayoría de los sistemas, esto ocurre con poca frecuencia y es de poca importancia.
Lo lamento por los gritos, pero cada vez que veo ''quantum'', ''renuncio al resto de su porción de tiempo'', ''round-robin'' y similares, solo me avergüenzo ...
Para complementar la respuesta de @usr, citando de Understanding the Linux Kernel :
La función schedule ()
schedule () implementa el planificador. Su objetivo es encontrar un proceso en la lista de runqueue y luego asignarle la CPU. Se invoca, directamente o de una manera perezosa, por varias rutinas del kernel. [...]
Invocación floja
El programador también se puede invocar de forma perezosa configurando el campo need_resched de [process] actual en 1. Como siempre se realiza una comprobación del valor de este campo antes de reanudar la ejecución de un proceso de User Mode (consulte la sección "Returning de Interrupts and Exceptions "en el Capítulo 4), schedule () definitivamente se invocará en algún futuro cercano cercano.