Une interruption est un événement "inhabituel" qui doit être traité immédiatement , indépendamment de tout ce qui se passe. Je dis «inhabituel» entre guillemets, car ils ne sont pas nécessairement inattendus ou mauvais, mais «inhabituels» du point de vue du CPU car ils «se produisent tout simplement» alors qu'il est occupé à exécuter du code qui peut ne pas être lié.
Le CPU dispose d'un mécanisme pour écouter les interruptions et d'une manière de configurer "ce qu'il faut faire" lorsque des interruptions de toutes sortes se produisent. Cela permet au système d'exploitation de faire en sorte qu'il soit averti lorsque les périphériques matériels font des choses (y compris l'horloge matérielle très importante, qui génère simplement des interruptions à intervalles réguliers). Grâce à la configuration de gestion des interruptions du CPU, le code désigné dans le système d'exploitation prendra le contrôle chaque fois que des interruptions se produisent.
L'ordinateur est dans un état très désagréable (pour un programmeur d'application) lorsqu'un gestionnaire d'interruption commence à s'exécuter; la machine était occupée à faire autre chose (qui pourrait être n'importe quoi ) et maintenant le système d'exploitation a été informé que "quelque chose s'est passé". Il doit rassembler toutes les autres informations nécessaires pour gérer réellement l'interruption de n'importe où dans la machine où il devrait se trouver et faire tout le traitement requis sans déranger que "pourrait être n'importe quoi" qui s'exécutait sur le CPU. Si le système d'exploitation souhaite changer le processus d'application en cours d'exécution, il devra enregistrer suffisamment de contexte pour pouvoir le restaurer plus tard (encore une fois, sans perturber ce contexte), puis charger un autre contexte, puis laisser le CPU reprendre son fonctionnement normal. exécution dans ce contexte.
Comme mentionné, les interruptions sont utilisées pour obtenir des notifications des périphériques matériels (la seule alternative serait de les vérifier périodiquement), de garder une trace du temps et d'obtenir l'opportunité garantie de reprendre le contrôle d'un processus d'application (afin de changer quelle application est en cours d'exécution) , récupération à partir de processus d'application exécutant des instructions non valides, et également pour permettre aux applications de faire des demandes au système d'exploitation. Ces derniers sont appelés appels système. Pour empêcher les applications de gâcher la machine et entre elles, elles s'exécutent normalement avec la machine en "mode utilisateur", ce qui empêche l'application de faire essentiellement autre chose que lire et écrire de la mémoire (virtuelle) qui lui est déjà allouée. Cela signifie que pour faire quoi que ce soitsinon (lecture / écriture de fichiers, demande de mémoire supplémentaire, accès aux appareils, etc.), l'application doit effectuer un appel système; il le fait essentiellement en laissant des informations sur ce qu'il veut faire quelque part, il sait que le système d'exploitation le recherchera, puis en exécutant une instruction CPU qui provoque une interruption du bon type. Le système d'exploitation peut alors voir ce que l'application essayait de faire et déterminer s'il doit exécuter cette demande. Cette garantie que le système d'exploitation sera impliqué dans toute tentative de processus de faire quoi que ce soit qui affecte quoi que ce soit en dehors du processus est la seule façon dont les politiques d'accès peuvent être appliquées.
Donc, essentiellement, oui, le système d'exploitation est entraîné par des interruptions. Un système d'exploitation «abstrait» amène la machine dans un état de «fonctionnement normal» et à un moment donné passe le contrôle à un processus «normal». Dans des circonstances normales, le système d'exploitation ne reprendra alors le contrôle qu'en gérant les interruptions; mais comme à peu près rien d'intéressant ne se produit sans interruption, le système d'exploitation a essentiellement le contrôle de tout tout le temps.
