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

19

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."]

operating-systems process-scheduling

— Ellen Spertus
source

Cette question semble demander des détails sur les systèmes d'exploitation qui, à mon humble avis, seraient hors sujet ici. Si ce n'est pas le cas, veuillez reformuler votre question en une plus abstraite.

— Raphael

3

Quand je l'ai posté sur le groupe Unix, on m'a dit que c'était inapproprié ici et qu'il appartenait ici, ce avec quoi j'étais d'accord, car il ne s'agissait pas d'un système d'exploitation spécifique. Je pense que celui-ci est comparable à la question sur la prédiction de branche. Il sera intéressant de voir ce que la communauté décide de ce qui est et n'est pas approprié ici.

— Ellen Spertus

15

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.

— Carl Mummert
source

11

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.

4

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.

— Ankit
source

2

De nombreux systèmes d'exploitation intégrés (y compris, mais sans s'y limiter, RTOS) ont une planification coopérative. Cela ne veut pas dire qu'il n'y a pas de planificateur; le planificateur est le code qui détermine le thread à exécuter ensuite. La préemption concerne la saisie automatique du planificateur par opposition à la demande de la tâche en cours d'exécution.

— Gilles 'SO- arrête d'être méchant'

@Gilles Joli commentaire (mise en ligne). Je suis d'accord avec vous que ce n'est pas complètement inutilisé. Ma réponse était simplement basée sur l'algorithme tel que défini à l'origine. AFIK, il est utilisé avec quelques modifications (avec un certain ordonnanceur). Je ne sais pas s'il a utilisé sa forme pure dans certains OS.

— Ankit

4

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.

— Pekka
source