La planification coopérative suspend-elle les processus lorsqu'ils effectuent une opération d'E / S?

De nombreuses références de systèmes d'exploitation disent qu'avec le multitâche coopératif (par opposition au multitâche préemptif), un processus maintient le CPU jusqu'à ce qu'il se suspende explicitement volontairement. Si un processus en cours exécute une demande d'E / S qui ne peut pas être immédiatement satisfaite (par exemple, demande un coup de clé qui n'est pas encore disponible), le planificateur la suspend-il ou garde-t-il vraiment le CPU jusqu'à ce que la demande puisse être traitée?

[Modifié pour remplacer "blocs sur les E / S" par "effectue une demande d'E / S qui ne peut pas être immédiatement satisfaite."]

Dans un cadre vraiment «coopératif», et s'il n'y avait pas de protection matérielle, un processus pourrait certainement bloquer les E / S et ne pas abandonner le contrôle jusqu'à ce que les E / S soient effectuées (ou ne jamais abandonner le contrôle du tout). Par exemple, Windows 3.1 était de cette façon: si un seul processus utilisateur voulait prendre le contrôle de tout l'ordinateur et empêcher l'exécution de quoi que ce soit d'autre, il le pouvait.

Mais sur un système multitâche, vous vous attendez à ce que les commandes d'E / S de l'API système abandonnent le contrôle du processeur lorsqu'elles sont appelées. Ainsi, lorsqu'un processus en cours d'exécution se bloque sur les E / S, en supposant que le processus utilise les API système normales, d'autres processus seront autorisés à s'exécuter jusqu'à ce que les E / S soient terminées, et finalement le processus d'origine reprendra une fois les E / S effectuées. . En d'autres termes, l'appel d'une fonction d'E / S bloquante est un moyen par lequel un processus sur un système coopératif peut se suspendre volontairement.

Si un processus en cours se bloque sur les E / S

Le blocage sur IO équivaut à peu près à la suspension de votre processus. Dans le contexte du noyau linux, l'exécution d'un appel système IO tel que read()provoquera le déclenchement d'un sysentergestionnaire d'interruption ou pour s'occuper de cet IO, appelant do_sys_read()finalement. Ici, si la demande en cours ne peut pas être satisfaite immédiatement, la fonction appelle sched()qui peut alors exécuter un autre processus.

Dans le contexte d'un système coopératif, je m'attends à ce que lorsque vous effectuez un appel système pour une raison d'E / S, si la demande ne peut pas être satisfaite, le noyau choisit une autre tâche et l'exécute. Ce document fournit quelques informations de base - en gros, si vous attendiez sur IO, vous pourriez être suspendu pour toujours en attendant cet IO. L'idée de l'ordonnancement coopératif est que vous appelez fréquemment sched()ou la méthode de renonciation à l'unité centrale équivalente, si vous effectuez des tâches gourmandes en CPU.

Les considérations en mode noyau deviennent plus intéressantes. Sur les architectures où elles sont disponibles telles que certaines plates - formes embarquées , les gestionnaires d'interruptions seront toujours invoqués en réponse à des interruptions matérielles ou logicielles. Il est généralement possible, au niveau de l'implémentation, de désactiver la gestion des interruptions , mais cela présente également des inconvénients.

Dans le cooperative multitaskingmodèle d' ordonnancement coopératif (de préférence ), il n'y a pas de concept d'ordonnanceur en ce sens que le système d'exploitation n'a aucun contrôle sur la durée du processus.

Une application correctement programmée abandonnerait volontairement le CPU sur les E / S. Mais, des applications mal écrites peuvent simplement continuer d'attendre les E / S, bloquant ainsi d'autres processus.

PS: Cette approche a ensuite été abandonnée par la plupart des OS en faveur de la planification préemptive (qui avait un ordonnanceur externe) et nous avons maintenant toutes sortes d'algorithmes de planification différents utilisés par différents OS.

EDIT: Ma réponse était basée sur le calendrier tel que décrit dans sa forme originale (il y a des années: P). Comme l'a fait remarquer Gilles, certains systèmes utilisent encore la programmation coopérative. Et il y a un planificateur. Je ne sais pas si ces systèmes utilisent COS dans sa forme pure et originale.

Le multitâche coopératif implique qu'un contexte d'exécution doit céder explicitement le contrôle à l'ordonnanceur et, s'il le souhaite, peut empêcher un changement de contexte de se produire.

La plupart des implémentations effectuent explicitement un changement de contexte pour tout appel système qui ne revient pas rapidement, et souvent même si c'est le cas, pour augmenter l'équité de l'allocation du processeur.

Habituellement, il est uniquement possible pour les processus ayant échoué (ou refusant intentionnellement le service au reste du système) d'empêcher un changement de tâche fréquent.

La préemption, comme l'explique Gilles, est une limitation de l'architecture du système qui empêche l'interruption temporisée de la tâche active et les changements de contexte forcés.