En attendant read() ou write() vers/depuis un retour de descripteur de fichier, le processus sera placé dans un type spécial de sommeil, connu sous le nom de "D" ou "Disk Sleep". Ceci est spécial, car le processus ne peut pas être tué ou interrompu dans un tel état. Un processus attendant un retour de ioctl() serait également mis en sommeil de cette manière.
Une exception à cela est lorsqu'un fichier (tel qu'un terminal ou un autre périphérique de caractères) est ouvert en O_NONBLOCK mode, transmis lorsqu'il est supposé qu'un périphérique (tel qu'un modem) aura besoin de temps pour s'initialiser. Cependant, vous avez indiqué des périphériques de blocage dans votre question. De plus, je n'ai jamais essayé un ioctl() susceptible de bloquer sur un fd ouvert en mode non bloquant (du moins pas sciemment).
La façon dont un autre processus est choisi dépend entièrement du planificateur que vous utilisez, ainsi que de ce que d'autres processus auraient pu faire pour modifier leurs poids dans ce planificateur.
Certains programmes de l'espace utilisateur dans certaines circonstances sont connus pour rester dans cet état pour toujours, jusqu'à ce qu'ils soient redémarrés. Ceux-ci sont généralement regroupés avec d'autres "zombies", mais le terme ne serait pas correct car ils ne sont pas techniquement obsolètes.
Un processus effectuant des E/S sera mis en état D (veille sans interruption) , qui libère le CPU jusqu'à ce qu'il y ait une interruption matérielle qui indique au CPU de revenir à l'exécution du programme. Voir man ps pour les autres états de processus.
Selon votre noyau, il existe un planificateur de processus , qui assure le suivi d'une file d'attente de processus prêts à être exécutés. Il, avec un algorithme de planification, indique au noyau quel processus attribuer à quel processeur. Il existe des processus noyau et des processus utilisateur à prendre en compte. Chaque processus se voit attribuer une tranche de temps, qui est un morceau de temps CPU qu'il est autorisé à utiliser. Une fois que le processus a utilisé toute sa tranche de temps, il est marqué comme expiré et reçoit une priorité inférieure dans l'algorithme de planification.
Dans le noyau 2.6 , il existe un ordonnanceur de complexité temporelle O(1) , donc quel que soit le nombre de processus en cours d'exécution, il affectera des processeurs en temps constant. C'est cependant plus compliqué, car la préemption 2.6 a introduit et l'équilibrage de charge CPU n'est pas un algorithme facile. Dans tous les cas, c'est efficace et les processeurs ne resteront pas inactifs pendant que vous attendez les E/S.
Lorsqu'un processus doit récupérer des données à partir d'un disque, il arrête effectivement de s'exécuter sur le processeur pour laisser les autres processus s'exécuter car l'opération peut prendre beaucoup de temps - au moins 5 ms de temps de recherche pour un disque est courant, et 5 ms est 10 millions Les cycles CPU, une éternité du point de vue du programme !
Du point de vue du programmeur (également dit "en espace utilisateur"), cela s'appelle un appel système bloquant . Si vous appelez le write(2) (qui est une mince enveloppe libc autour de l'appel système du même nom), votre processus ne s'arrête pas exactement à cette limite ; il continue, dans le noyau, à exécuter le code d'appel système. La plupart du temps, il va jusqu'à un pilote de contrôleur de disque spécifique (nom de fichier → système de fichiers/VFS → périphérique de bloc → pilote de périphérique), où une commande pour récupérer un bloc sur le disque est soumise au matériel approprié, ce qui est très fonctionnement rapide la plupart du temps.
PUIS le processus est mis en état de veille (dans l'espace du noyau, le blocage s'appelle dormir - rien n'est jamais "bloqué" du point de vue du noyau). Il sera réveillé une fois que le matériel aura finalement récupéré les données appropriées, puis le processus sera marqué comme exécutable et sera programmé. Finalement, le planificateur exécutera le processus.
Enfin, dans l'espace utilisateur, l'appel système de blocage revient avec le statut et les données appropriés, et le déroulement du programme continue.
Il est possible d'invoquer la plupart des appels système d'E/S en mode non bloquant (voir O_NONBLOCK en open(2) et fcntl(2) ). Dans ce cas, les appels système reviennent immédiatement et signalent uniquement la soumission de l'opération de disque. Le programmeur devra explicitement vérifier ultérieurement si l'opération s'est terminée, avec succès ou non, et récupérer son résultat (par exemple, avec select(2) ). C'est ce qu'on appelle la programmation asynchrone ou événementielle.
La plupart des réponses ci-dessous mentionnent l'état D (qui s'appelle TASK_UNINTERRUPTIBLE dans les noms d'état Linux) sont incorrects. Le D state est un mode veille spécial qui n'est déclenché que dans un chemin de code de l'espace noyau, lorsque ce chemin de code ne peut pas être interrompu (car ce serait trop complexe à programmer), dans l'espoir qu'il ne bloquerait que très peu de temps. Je crois que la plupart des "états D" sont en fait invisibles ; ils sont de très courte durée et ne peuvent pas être observés par des outils d'échantillonnage tels que "top".
Vous pouvez rencontrer des processus non tuables à l'état D dans quelques situations. NFS est célèbre pour cela, et je l'ai rencontré plusieurs fois. Je pense qu'il y a un conflit sémantique entre certains chemins de code VFS, qui supposent d'atteindre toujours les disques locaux et une détection d'erreur rapide (sur SATA, un délai d'attente d'erreur serait d'environ quelques 100 ms), et NFS, qui récupère en fait les données du réseau qui est plus résilient et a une récupération lente (un délai TCP de 300 secondes est courant). Lisez cet article pour la solution cool introduite dans Linux 2.6.25 avec le TASK_KILLABLE Etat. Avant cette époque, il y avait un hack où vous pouviez réellement envoyer des signaux aux clients de processus NFS en envoyant un SIGKILL au thread du noyau rpciod , mais oubliez cette vilaine astuce.…