Bienvenido a nuestra página web, aquí hallarás la respuesta que buscas.
Solución:
Cuando un proceso necesita obtener datos de un disco, efectivamente deja de ejecutarse en la CPU para permitir que otros procesos se ejecuten porque la operación puede tardar mucho en completarse; al menos 5ms de tiempo de búsqueda para un disco es común y 5ms son 10 millones. Ciclos de CPU, ¡una eternidad desde el punto de vista del programa!
Desde el punto de vista del programador (también llamado “en el espacio de usuario”), esto se llama bloqueo de llamada al sistema. Si llamas write(2) (que es una envoltura delgada de libc alrededor de la llamada al sistema del mismo nombre), su proceso no se detiene exactamente en ese límite; continúa, en el kernel, ejecutando el código de llamada del sistema. La mayoría de las veces llega hasta un controlador de controlador de disco específico (nombre de archivo → sistema de archivos / VFS → dispositivo de bloque → controlador de dispositivo), donde se envía un comando para buscar un bloque en el disco al hardware adecuado, que es muy operación rápida la mayor parte del tiempo.
ENTONCES se pone el proceso en estado de sueño (en el espacio del kernel, el bloqueo se llama dormir; nada se ‘bloquea’ desde el punto de vista del kernel). Se activará una vez que el hardware finalmente haya obtenido los datos adecuados, luego el proceso se marcará como ejecutable y se programará. Finalmente, el programador ejecutará el proceso.
Finalmente, en el espacio de usuario, el bloqueo de llamada al sistema regresa con el estado y los datos adecuados, y el flujo del programa continúa.
Es posible invocar la mayoría de las llamadas al sistema de E / S en modo sin bloqueo (ver O_NONBLOCK en open(2) y fcntl(2)). En este caso, las llamadas al sistema regresan de inmediato y solo informan sobre el envío de la operación del disco. El programador tendrá que verificar explícitamente en un momento posterior si la operación se completó, con éxito o no, y buscar su resultado (por ejemplo, con select(2)). A esto se le llama programación asíncrona o basada en eventos.
La mayoría de las respuestas aquí mencionan Estado D (Lo que es llamado TASK_UNINTERRUPTIBLE en los nombres de estado de Linux) son incorrectos. los D El estado es un modo de suspensión especial que solo se activa en una ruta de código de espacio del kernel, cuando esa ruta de código no puede ser interrumpido (porque sería demasiado complejo de programar), con la expectativa de que se bloqueara solo por un tiempo muy corto. Creo que la mayoría de los “estados D” son en realidad invisibles; tienen una vida muy corta y no se pueden observar con herramientas de muestreo como ‘top’.
Puede encontrar procesos que no se pueden matar en el estado D en algunas situaciones. NFS es famoso por eso y lo he encontrado muchas veces. Creo que hay un choque semántico entre algunas rutas de código VFS, que asumen que siempre llegan a los discos locales y la detección rápida de errores (en SATA, un tiempo de espera de error sería de unos 100 ms), y NFS, que en realidad obtiene datos de la red que es más resistente y tiene una recuperación lenta (un tiempo de espera de TCP de 300 segundos es común). Lea este artículo para conocer la excelente solución introducida en Linux 2.6.25 con el TASK_KILLABLE estado. Antes de esta era, había un truco en el que se podían enviar señales a los clientes de procesos NFS enviando un SIGKILL al hilo del kernel. rpciod, pero olvídate de ese feo truco …
Mientras se espera read() o write() a / desde un retorno de descriptor de archivo, el proceso se pondrá en un tipo especial de suspensión, conocido como “D” o “Disk Sleep”. Esto es especial, porque el proceso no se puede matar ni interrumpir mientras se encuentra en tal estado. Un proceso que espera un retorno de ioctl () también se pondría en reposo de esta manera.
Una excepción a esto es cuando un archivo (como un terminal u otro dispositivo de caracteres) se abre en O_NONBLOCK modo, pasado cuando se asume que un dispositivo (como un módem) necesitará tiempo para inicializarse. Sin embargo, indicó dispositivos de bloqueo en su pregunta. Además, nunca he probado un ioctl() que es probable que se bloquee en un fd abierto en modo sin bloqueo (al menos sin saberlo).
La forma en que se elige otro proceso depende completamente del programador que esté utilizando, así como de lo que otros procesos podrían haber hecho para modificar sus pesos dentro de ese programador.
Se sabe que algunos programas de espacio de usuario en determinadas circunstancias permanecen en este estado para siempre, hasta que se reinician. Por lo general, estos se agrupan con otros “zombis”, pero el término no sería correcto ya que técnicamente no están extintos.
Se colocará un proceso que realiza E / S Estado D (sueño ininterrumpido), que libera la CPU hasta que se produce una interrupción de hardware que le indica a la CPU que vuelva a ejecutar el programa. Ver man ps para los otros estados del proceso.
Dependiendo de su kernel, hay una planificador de procesos, que realiza un seguimiento de una cola de ejecución de procesos listos para ejecutarse. Junto con un algoritmo de programación, le dice al kernel qué proceso asignar a qué CPU. Hay procesos de kernel y procesos de usuario a considerar. A cada proceso se le asigna un intervalo de tiempo, que es una parte del tiempo de CPU que se le permite usar. Una vez que el proceso utiliza todo su intervalo de tiempo, se marca como vencido y se le da menor prioridad en el algoritmo de programación.
En el 2.6 kernel, hay un O (1) programador de complejidad de tiempo, por lo que no importa cuántos procesos tenga en ejecución, asignará CPU en tiempo constante. Sin embargo, es más complicado, ya que 2.6 introdujo la preferencia y el equilibrio de carga de la CPU no es un algoritmo fácil. En cualquier caso, es eficiente y las CPU no permanecerán inactivas mientras espera la E / S.
Reseñas y calificaciones
Recuerda que puedes optar por la opción de valorar esta noticia si te fue preciso.