Comment fonctionne le multitâche


15

Je ne sais absolument rien du fonctionnement interne d'un système d'exploitation, mais je peux plus ou moins deviner le comportement approximatif de nombreuses fonctions. Une chose que je ne peux pas comprendre, cependant, est le multitâche.

En théorie, le système d'exploitation gère le temps, en accordant le CPU pour de petits intervalles aux différents programmes en cours d'exécution. Mais on ne sait pas comment cela vraiment fonctionne.

Supposons que le système d'exploitation veuille démarrer mon programme. Le code machine est chargé quelque part dans la RAM, à partir d'une certaine adresse. Je suppose alors qu'un saut devrait être effectué à cette adresse, permettant à mon code de s'exécuter. Mais de cette façon, le système d'exploitation ne peut reprendre le contrôle avant que je ne recule.

Fondamentalement, je peux imaginer seulement deux façons de faire ce travail, mais aucune ne semble vraiment appropriée:

  • Le système d'exploitation peut lire les instructions de la machine que je souhaite exécuter et les émuler au lieu de les exécuter directement. Je suis intentionnellement vague, car je ne sais pas comment cela fonctionnerait, mais il semble que cela ralentirait considérablement le programme.

  • Alternativement, le système d'exploitation peut attendre que j'effectue un appel système. À ce moment-là, il reprend le contrôle et peut vérifier combien de temps j'ai couru et faire son travail en temps partagé. Cela peut fonctionner, mais cela semble peu fiable, car je pourrais faire un long calcul qui n'implique pas d'appels système et tout bloquer pendant un certain temps.

Il semble donc qu'aucun des deux mécanismes ne fonctionnerait très bien. Comment le multitâche est-il réellement exécuté?


Bien que votre supposition ne soit pas exactement correcte, le problème que vous signalez est, eh bien, oui: "Je pourrais faire un long calcul qui n'implique pas d'appels système et tout bloquer pendant un certain temps."
jhocking

Un mot clé à rechercher:interrupt
SK-logic

Oui, mais qui lance l'interruption? Si mon code est en cours d'exécution, le système d'exploitation n'a aucun moyen d'exécuter une INTinstruction. Quelque chose est encore mystérieux pour moi
Andrea

@Andrea, l'horloge matérielle déclenche une interruption. Aussi simple que ça. en.wikipedia.org/wiki/Scheduling_%28computing%29
SK-logic

Ok, maintenant je vois. Donc, si je comprends bien, c'est une fonctionnalité matérielle, pas quelque chose que l'on peut simplement implémenter dans le système d'exploitation.
Andrea

Réponses:


21

Le système d'exploitation programme une minuterie pour déclencher toutes les quelques microsecondes (ou millisecondes, selon la vitesse du système). Ce temporisateur déclenche l'interruption matérielle, ce qui oblige la CPU à arrêter tout ce qu'elle fait actuellement, à vider tout son contenu sur la pile et à traiter la routine d'interruption indiquée par l'adresse fournie par le contrôleur d'interruption. Cette routine peut inspecter la pile et diverses autres variables pour décider quel processus en cours d'exécution devrait ensuite être remis en action. S'il s'agit du même processus, la routine d'interruption revient simplement. Si elle est différente, les parties pertinentes de la pile sont enregistrées puis remplacées par le contenu d'un processus précédemment interrompu, donc lorsque la routine d'interruption revient, ce processus continue. Outre le fait qu’il s’est écoulé un certain temps,

Il s'agit (pour les processeurs modernes) d'une version TRÈS TRÈS simplifiée de ce qui se passe, mais cela explique le principe. En plus de ces interruptions contrôlées par le système d'exploitation, il existe également des interruptions causées par des événements externes (souris, clavier, ports série, ports réseau, etc.) qui sont traités avec des routines d'interruption distinctes, qui sont généralement connectées à des gestionnaires d'événements.

Très souvent, la commutation de processus / tâche / contexte est également basée sur la disponibilité des ressources externes. En règle générale, un processus qui nécessite des données de stockage (c'est-à-dire ne se trouvant pas dans la mémoire RAM) place la demande dans une file d'attente, définit un gestionnaire d'événements pour l'interruption matérielle indiquant que la demande a été servie, puis abandonne le contrôle au planificateur de tâches (puisqu'il n'y a pas de point en attente). Encore une fois, une description très simplifiée de ce qui se passe réellement, mais elle devrait servir les objectifs de cette réponse.


5

Cela varie d'un système à l'autre.

Dans les systèmes multitâches non préventifs (tels que l'Oberon d'origine ou l'Apple Macintosh d'origine), le système d'exploitation "interroge" périodiquement toutes les tâches, leur donnant ainsi la possibilité de travailler. Les tâches devraient bien jouer ensemble. S'ils ont juste un peu de travail à faire, ils le font et reviennent à l'OS. Si une tâche a un GROS morceau à faire, il est prévu de le diviser en petits morceaux et de travailler un petit morceau chaque fois qu'il est interrogé.

Les interruptions matérielles (achèvement du lecteur de disque DMA, interruptions du port série, etc.) provoquent l'exécution de routines d'interruption. Ces routines d'interruption peuvent à leur tour notifier les tâches à effectuer lors de la prochaine exécution de la tâche.

Dans les systèmes multitâches non préventifs, l'occurrence ou la non-occurrence d'une interruption n'affecte pas la tâche en cours d'exécution une fois la routine d'interruption terminée.

Dans les systèmes multitâches préemptifs, il est possible qu'une routine d'interruption force un changement de programmation. Dans un système multitâche préemptif à tour de rôle traditionnel, une interruption de minuterie périodique fait exactement cela. L'interruption du minuteur se déclenche, la routine d'interruption du minuteur fait un peu de magie noire pour que l'instruction de retour d'interruption revienne à la planification préemptive du système d'exploitation, plutôt qu'à la tâche en cours d'exécution, éloignant le processeur de la tâche en cours, et (POSSIBLEMENT ) en le donnant à une autre tâche. Si aucune autre tâche n'est prête à s'exécuter à ce stade, la tâche en cours récupérera le processeur, n'ayant perdu qu'un peu de temps.

Le multitâche préemptif peut causer BEAUCOUP de problèmes. Tous ces trucs ennuyeux sur les mutex et les sections critiques et les étreintes mortelles et les inversions de priorité et ... apparaissent lorsque le processeur vous est retiré sans avertissement. Vous devez utiliser toutes ces choses pour dire au système d'exploitation que vous êtes en train de mélanger de la nitroglycérine et que vous retirer le processeur en ce moment est susceptible d'entraîner un grand trou virtuel fumant au milieu du plancher de la salle des serveurs.


Qu'est-ce qui peut arriver si le processeur vous est retiré sans avertissement? Je suppose que vous obtiendrez à nouveau le contrôle du processeur avec les mêmes valeurs dans les registres. En quoi est-ce différent de simplement garder votre calcul?
Andrea

@Andrea: l'exclusion mutuelle et les sections critiques consistent à ne pas perdre le processeur à un moment critique. Si votre processus a quelque chose de verrouillé et que vous perdez le processeur, ce quelque chose reste verrouillé jusqu'à ce que vous obteniez à nouveau le processeur. Cela peut provoquer des problèmes.
John R. Strohm

@Andrea Vous reprendrez le contrôle du processeur et un autre processus peut avoir manipulé la mémoire que vous étiez sur le point d'utiliser.
user253751

4

Des interruptions de minuterie peuvent être générées par le matériel informatique pour interrompre le processeur. De cette façon, en fonction de l'algorithme de planification utilisé par le système d'exploitation, le système d'exploitation peut décider de continuer à exécuter votre programme actuel ou de basculer le contexte vers un autre qui est prêt à être exécuté.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.