A la espera de 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 puede ser eliminado o interrumpido mientras se encuentra en dicho estado. Un proceso que espera un retorno de ioctl() también se suspendería de esta manera.
Una excepción a esto es cuando un archivo (como una terminal u otro dispositivo de caracteres) se abre en O_NONBLOCK modo, pasado cuando se supone que un dispositivo (como un módem) necesitará tiempo para inicializarse. Sin embargo, indicó bloquear dispositivos 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, en determinadas circunstancias, algunos programas de espacio de usuario permanecen en este estado para siempre, hasta que se reinician. Por lo general, se agrupan con otros "zombis", pero el término no sería correcto ya que técnicamente no están extintos.
Un proceso que realiza E/S se pondrá en estado D (suspensión ininterrumpida) , que libera la CPU hasta que se produce una interrupción de hardware que le dice a la CPU que vuelva a ejecutar el programa. Ver man ps para los demás estados del proceso.
Dependiendo de su kernel, hay un programador de procesos , que realiza un seguimiento de una cola de ejecución de procesos listos para ejecutar. 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 segmento 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 caducado y se le otorga menor prioridad en el algoritmo de programación.
En el núcleo 2.6 , hay un programador de complejidad de tiempo O(1) , 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.
Cuando un proceso necesita obtener datos de un disco, deja de ejecutarse en la CPU para permitir que se ejecuten otros procesos porque la operación puede tardar mucho tiempo en completarse:al menos 5 ms de tiempo de búsqueda para un disco es común, y 5 ms 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 denomina llamada al sistema de bloqueo . Si llamas al write(2) (que es un contenedor libc delgado 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 al sistema. La mayoría de las veces va 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, lo cual es muy funcionamiento rápido la mayor parte del tiempo.
ENTONCES el proceso se pone en estado de suspensión (en el espacio del kernel, el bloqueo se llama dormir; nada se 'bloquea' nunca 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á. Eventualmente, el programador ejecutará el proceso.
Finalmente, en el espacio de usuario, la llamada al sistema de bloqueo regresa con el estado y los datos correctos, y el flujo del programa continúa.
Es posible invocar la mayoría de las llamadas del 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 inmediatamente y solo informan 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 obtener su resultado (por ejemplo, con select(2) ). Esto se denomina programación asíncrona o basada en eventos.
La mayoría de las respuestas aquí mencionan el estado D (que se llama TASK_UNINTERRUPTIBLE en los nombres de estado de Linux) son incorrectos. La D state 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 se puede interrumpir (porque sería demasiado complejo de programar), con la expectativa de que se bloquearía 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 'superior'.
Puede encontrar procesos indestructibles en el estado D en algunas situaciones. NFS es famoso por eso, y lo he encontrado muchas veces. Creo que hay un conflicto semántico entre algunas rutas de código VFS, que asumen que siempre alcanzan 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 genial solución introducida en Linux 2.6.25 con el TASK_KILLABLE estado. Antes de esta era, había un truco en el que en realidad podía enviar señales a los clientes de procesos NFS enviando un SIGKILL al subproceso del núcleo rpciod , pero olvídate de ese feo truco.…