¿Cómo recupera el programador del sistema operativo el control de la CPU?
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 multitarea.
Como tal, suponiendo que mi máquina tiene una sola CPU, esto significaría que, en un momento dado, solo se podría ejecutar un proceso.
Ahora, solo puedo asumir que el programador utilizado por el sistema operativo para controlar el acceso al valioso tiempo de CPU también es un proceso.
Por lo tanto, en esta máquina, ya sea el proceso de usuario o el proceso del sistema de programación se está ejecutando en cualquier momento dado, pero no 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 un proceso dado que se está ejecutando actualmente no cede (cede) la CPU, ¿cómo podría el propio programador volver a ejecutarse y garantizar la multitarea?
Hasta ahora, había 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 asegurarnos de que el programador tenga asignado algún tiempo de CPU nuevamente. Pero ni siquiera estoy seguro de si esto funciona de esta manera.
Por otro lado, si el proceso de usuario en cuestión estuviera inherentemente ligado a la CPU, entonces, desde este punto de vista, podría ejecutarse para siempre, nunca dejando que otros procesos, ni siquiera el planificador se ejecuten de nuevo.
Suponiendo que a programación en el tiempo, no tengo idea de cómo el programador podría cortar el tiempo para la ejecución de otro proceso, cuando ni siquiera se está ejecutando?
Realmente apreciaría cualquier información o referencias que pueda proporcionar en este sentido.
3 answers
El sistema operativo establece un temporizador de hardware (Programable interval timer o PIT) que genera una interrupción cada N milisegundos. Esa interrupción se envía al núcleo y el código de usuario se interrumpe.
Funciona como cualquier otra interrupción de hardware. Por ejemplo, su disco forzará un cambio al núcleo cuando haya completado un IO.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-03-25 03:13:54
Google 'interrumpe'. Las interrupciones están en el centro de los kernels preventivos de multiproceso como Linux/Windows. Sin interrupciones, el sistema operativo nunca hará nada.
Mientras investigas/aprendes, trata de ignorar cualquier explicación que mencione 'interrupción del temporizador', 'round-robin' y 'time-slice', 'quantum' en el primer párrafo - son peligrosamente engañosas, si no realmente erróneas.
Las interrupciones, en términos de sistema operativo, vienen en dos sabores:
Interrupciones de hardware-aquellos iniciado por una señal de hardware real de un dispositivo periférico. Estos pueden ocurrir en, (casi) cualquier momento y cambiar la ejecución de cualquier subproceso que se esté ejecutando al código en un controlador.
Interrupciones de software - aquellas iniciadas por llamadas al sistema operativo desde subprocesos actualmente en ejecución.
Cualquiera de las dos interrupciones puede solicitar al programador que haga que los subprocesos que estaban esperando estén listos/en ejecución o que los subprocesos que estaban esperando/en ejecución se anticipen.
LAS INTERRUPCIONES MÁS IMPORTANTES SON AQUELLAS INTERRUPCIONES DE HARDWARE DE CONTROLADORES PERIFÉRICOS, - aquellos que hacen hilos listos que estaban esperando en IO de discos, tarjetas NIC, ratones, teclados, USB, etc. La razón principal para usar kernels preventivos, y todos los problemas de bloqueo, sincronización, señalización, etc., es que tales sistemas tienen UN MUY BUEN RENDIMIENTO DE IO PORQUE LOS PERIFÉRICOS DE HARDWARE PUEDEN HACER QUE LOS SUBPROCESOS ESTÉN LISTOS/EJECUTANDO ESE WARE ESPERANDO DATOS DE ESE HARDWARE, SIN NINGUNA LATENCIA RESULTANTE DE SUBPROCESOS QUE NO RINDEN O ESPERANDO UNA REPROGRAMACIÓN PERIÓDICA DEL TEMPORIZADOR.
La interrupción del temporizador de hardware que causa ejecuciones periódicas de 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 que debería.
En sistemas multinúcleo, el sistema operativo tiene un controlador de interprocesador que puede causar una interrupción de hardware en otros núcleos, lo que permite que el sistema operativo interrumpa/programe/envíe subprocesos en múltiples núcleos.
En cajas seriamente sobrecargadas, o aquellos al ejecutar aplicaciones con uso intensivo de 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 subprocesos listos que es mayor que el número de núcleos disponibles y, por lo tanto, permitir a cada uno una parte de los recursos de CPU disponibles. En la mayoría de los sistemas, esto sucede raramente y es de poca importancia.
Lo siento por los gritos, pero cada vez que veo 'quantum', 'renunciar al resto de su rebanada de tiempo', 'round-robin' y similares, yo solo cringe..
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-14 09:56:20
Para complementar la respuesta de @usr, citando Entendiendo el Kernel de Linux :
La Función schedule ()
Schedule( ) implementa el scheduler. Su objetivo es encontrar un procesar en la lista runqueue y luego asignarle la CPU. Es invocado, directamente o de manera perezosa, por varias rutinas del núcleo. [...]
Invocación perezosa
El scheduler también se puede invocar de forma perezosa configurando el campo need_resched del [proceso] actual a 1. Desde un control sobre el valor de este el campo siempre se realiza antes de reanudar la ejecución de un Modo de usuario proceso (vea la sección "Regresar de Interrupciones y Excepciones" en Capítulo 4), schedule () definitivamente será invocado en algún tiempo futuro.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-01-09 10:54:05