Signale et interrompt une comparaison
Sur la base de diverses références, ma définition subjective de les signaux sous Linux est "Les déclencheurs qui sont utilisés pour notifier les processus d'une occurrence d'un événement spécifique. L'événement ici peut faire référence à une exception logicielle. Des signaux supplémentaires peuvent également être utilisés pour IPC. " Les questions que j'ai sont
- Je suppose que seules les exceptions (interruptions logicielles) sont notifiées via des signaux. Qu'en est-il du cas des interruptions matérielles.
- Quelles sont les différentes sources du signal? Pour moi, il semble que le noyau soit toujours la source d'un signal (sauf lorsqu'il est utilisé pour IPC)
- Différence entre le gestionnaire de signal et l'ISR ?.
- Différence entre le blocage du signal et le masquage d'interruption?
Les interruptions peuvent être considérées comme un moyen de communication entre le CPU et le noyau du système d'exploitation. Les signaux peuvent être considérés comme un moyen de communication entre le noyau du système d'exploitation et les processus du système d'exploitation.
Les interruptions peuvent être déclenchées par le CPU (exceptions - par exemple: division par zéro, défaut de page), les appareils (interruptions matérielles - par exemple: entrée disponible), ou par une instruction du CPU (traps - par exemple: appels système, points d'arrêt). Ils sont finalement gérés par le CPU, qui "interrompt" la tâche en cours et appelle un gestionnaire ISR/interruption fourni par le noyau du système d'exploitation.
Les signaux peuvent être initiés par le noyau du système d'exploitation (par exemple: SIGFPE, SIGSEGV, SIGIO) ou par un processus (kill ()). Ils sont finalement gérés par le noyau du système d'exploitation, qui les délivre au thread/processus cible, en invoquant soit une action générique (ignorer, terminer, terminer et vider le noyau) ou un gestionnaire de signaux fourni par le processus.
Je suppose que seules les exceptions (interruptions logicielles) sont notifiées via des signaux. Qu'en est-il du cas des interruptions matérielles.
Où commencer ? Il y a beaucoup de cas différents. Gardez à l'esprit que les interruptions sont le matériel appelant le processeur. Les interruptions se composent essentiellement de "le matériel a besoin d'attention" et d'un nombre compris entre 0 et 255. Les signaux sont similaires mais ont 2 paramètres: l'identifiant du processus de destination et un int (32 bits ou 64 bits, selon Arch). Les interruptions matérielles sont toujours gérées dans l'espace du noyau, tandis que les signaux sont uniquement des éléments de l'espace utilisateur. Le noyau utilise des interruptions matérielles pour diverses raisons.
Un exemple d'interruption matérielle qui n'a rien à voir avec les signaux est le sous-système VM. Vous savez que sur les systèmes d'exploitation modernes, vous pouvez allouer plus de mémoire qu'il n'en existe réellement sur le système. Alors, comment cela Cela fonctionne en exploitant les interruptions matérielles. Lorsque vous allouez de la mémoire, le noyau en prend note, mais ne fait rien du tout. Ensuite, lorsque vous essayez d'accéder à la mémoire allouée, le processeur va se plaindre "mais cette mémoire n'existe pas", ce qui générera une interruption matérielle. Le noyau va parcourir ses notes, constater que vous avez effectivement demandé cette mémoire, effacer de la mémoire disponible et dire au processeur de "mapper" cette mémoire à l'emplacement prévu. Après quoi, le noyau reprend votre programme juste avant l'interruption matérielle et cette fois le processus trouvera la mémoire très bien.
Le multitâche est également mis en œuvre en exploitant une interruption matérielle. Tous les pilotes fonctionnent généralement en interprétant les interruptions.
Les signaux sont utilisés pour communiquer entre les processus. Quelque chose de très "signal-y" serait le comportement commun des démons Linux pour recharger leur configuration sur SIGHUP, aimé et détesté par les administrateurs système partout dans le monde. Lorsque vous modifiez, par exemple, une configuration Apache, le processus ne démarre pas automatiquement à l'aide de la nouvelle configuration. Vous pouvez terminer et redémarrer le processus, mais cela signifie que 4 à 5 secondes, votre serveur http sera hors de portée. Donc, vous pouvez plutôt "killall -HUP Apache". Cela va appeler un sous-programme dans le processus Apache, ce qui lui fera relire son fichier de configuration.
La suspension de processus est implémentée via des signaux (ctrl-z), une interruption de processus (ctrl-c), un arrêt de processus (ctrl-), des déconnexions de terminal (soupir), ... une liste plus complète peut être trouvée ici: http : //en.wikipedia.org/wiki/Unix_signal .
Une conclusion pourrait être qu'ils sont en quelque sorte similaires, mais ils fonctionnent à un niveau différent: les interruptions matérielles sont, eh bien, le matériel appelle l'attention, et le logiciel le plus bas oblige. Généralement, le noyau gère tout le matériel et les processus d'information se font quelque peu indépendamment des interruptions matérielles. Pour un certain nombre de signaux, la gestion par défaut est fournie (par exemple, ctrl-z, ctrl-c, ...), pour d'autres, la mise en œuvre dépend très de l'application (par exemple SIGHUP).
En ce qui concerne les signaux, ils ne sont définis que par logiciel. Ils font tout ce que vous voulez qu'ils fassent, et Linux est livré avec des méthodes pratiques pour appeler ces sous-programmes. Dans certains cas, le noyau peut appeler une routine de signal (par exemple SIGSEGV, SIGCHILD, ...), mais cela n'implique presque jamais de matériel. Ils sont juste un moyen pratique de déclencher une routine spécifique dans une application.
Il y avait un cas particulier: l'interruption "OS", en DOS 21h. Ce n'est plus utilisé (mais fonctionne toujours), mais l'idée est la suivante. Un programme peut déclencher une interruption spécifique pour demander au noyau d'effectuer des actions spécifiques. Les actions étant les syscalls (ouverture d'un fichier, fermeture d'un socket, qu'avez-vous). Comme je l'ai dit, intéressant, mais plus vraiment utilisé.
Quelles sont les différentes sources du signal? Pour moi, il semble que le noyau soit toujours la source d'un signal (sauf lorsqu'il est utilisé pour IPC)
Un signal provient soit du processus lui-même (SIGABRT), soit du noyau (SIGSEGV, ...) ou d'autres processus, comme le Shell par exemple (ctrl-z, ctrl-c, ctrl- \, ...) ou de tuer. Mais ils peuvent provenir de n'importe quel autre programme en utilisant la fonction kill libc:
#include <sys/types.h>
#include <signal.h>
int kill(pid_t pid, int sig);
Différence entre le gestionnaire de signal et l'ISR ?.
La principale différence est que les ISR vivent dans l'espace du noyau et doivent tenir compte du fait que l'ordinateur entier est gelé lors de leur exécution. Cela signifie qu'ils peuvent avoir interrompu n'importe quel processus et n'importe quoi dans le noyau. Ils "arrêtent également le monde". Pendant le traitement d'une interruption, rien d'autre ne se produira. Donc, si un gestionnaire d'interruption attend quelque chose, la machine se bloque. Si un gestionnaire d'interruption entre dans une boucle, votre seule option est de redémarrer la machine.
Les ISR sont vraiment difficiles à obtenir correctement. Il y a beaucoup de théorie sur eux, sur Linux, ils ont la moitié supérieure et la moitié inférieure, avec toutes sortes de traitement prioritaire, d'allocation de mémoire spéciale, ... et c'est un champ de mines. Un pas dans la mauvaise direction dans un ISR tuera la machine. Un bogue dans un ISR entraînera une perte de données, voire une panne matérielle pure et simple. En fait, par expérience, le simple fait de soupçonner que vous envisagez de faire quelque chose de mal dans un ISR entraîne immédiatement un comportement complètement imprévisible de la machine.
Vous ne pouvez pas utiliser les fonctionnalités du noyau dans les ISR. Ouverture d'un fichier, oubliez-le. Allouer de la mémoire, oubliez-le. Appelez n'importe quelle autre partie du noyau, oubliez-le (à quelques exceptions près, mais seulement quelques-unes). La liste continue.
Les signaux ne sont que des fonctions dans des processus spécifiques appelés. Un signal peut bloquer (par exemple ctrl-z) et cela arrêtera le processus de progresser, mais par exemple, votre session Shell répondra toujours. Le processus doit tenir compte du fait que n'importe quelle partie du programme peut avoir été interrompue bien sûr, mais c'est toujours un espace utilisateur normal. Vous pouvez bloquer, vous pouvez boucler, vous pouvez ouvrir des fichiers, allouer de la mémoire, ... tout ce que vous voulez.
Différence entre le blocage du signal et le masquage d'interruption?
Ils sont assez similaires. Sauf que le blocage du signal se fait par processus. Dans les deux cas, il y a des signaux non bloquables, et il y a un NMI (interruption non masquable) (les deux indiquent des erreurs graves).
À la fin, les signaux et les interruptions envoient un nombre, soit au noyau, soit à un processus spécifique. Le blocage du signal et le masquage d'interruption signifient simplement que le système doit ignorer des numéros spécifiques.
Une différence est que le masquage d'interruption est implémenté dans le matériel.
Les signaux et les interruptions se comportent de manière assez similaire. La différence est que les signaux arrivent à un processus (qui vit dans un environnement virtuel), tandis que les exceptions sont à l'échelle du système.
Certains défauts sont signalés par le CPU à titre d'exception, puis mappés sur un signal délivré au processus par le noyau. Le noyau peut choisir de masquer toute exception du processus (par exemple, les accès à la mémoire non mappée sont corrigés en silence par la pagination).
Les interruptions matérielles sont simplement une sorte d'exception, que le noyau peut choisir de mapper à un signal (par exemple, si vous utilisez alarm(2)).
Le noyau génère des signaux en réponse à divers événements, parmi lesquels les exceptions, l'achèvement des E/S, les demandes explicites d'espace utilisateur, ...
Les gestionnaires de signaux se comportent de la même manière que les ISR - ils peuvent être invoqués à tout moment, donc ils ne peuvent faire aucune hypothèse sur l'état du programme, tout comme les ISR - et les signaux de blocage se comportent de la même manière à l'intérieur de l'espace d'adressage virtuel que les interruptions de masquage. sur la machine physique.