Signaux et interrompt une comparaison

Sur la base de diverses références, ma définition subjective des signaux sous Linux est la suivante: «Les déclencheurs utilisés pour notifier les processus à propos d’une occurrence d’un événement spécifique. L’événement peut faire référence à une exception logicielle. “ Les questions que j’ai sont

  • Je présume 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, le kernel est toujours la source d’un signal (sauf s’il est utilisé pour IPC)
  • Différence entre le gestionnaire de signaux et les 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 processeur et le kernel du système d’exploitation. Les signaux peuvent être considérés comme un moyen de communication entre le kernel du système d’exploitation et les processus du système d’exploitation.

Des interruptions peuvent être déclenchées par la CPU (exceptions – par exemple: division par zéro, défaut de page), périphériques (interruptions matérielles – par exemple: entrée disponible), ou par une instruction de processeur (traps – par exemple: appels système, points d’arrêt). Ils sont finalement gérés par la CPU, qui “interrompt” la tâche en cours et appelle un gestionnaire ISR / interruption fourni par le kernel OS.

Les signaux peuvent être initiés par le kernel du système d’exploitation (par exemple: SIGFPE, SIGSEGV, SIGIO) ou par un processus (kill ()). Ils sont finalement gérés par le kernel du système d’exploitation, qui les transmet au thread / processus cible, en invoquant une action générique (ignorer, terminer, terminer et dump core) ou un gestionnaire de signal fourni par le processus.

Je présume 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 consistent essentiellement en un “matériel nécessitant une attention” et un nombre compris entre 0 et 255. Les signaux sont similaires mais ont deux parameters: l’identifiant du processus de destination et un int (32 bits ou 64 bits, selon l’arch). Les interruptions matérielles sont toujours gérées dans l’espace kernel, alors que les signaux ne sont que des objects de l’espace utilisateur. Le kernel utilise des interruptions matérielles pour diverses raisons.

Le sous-système VM est un exemple d’interruption matérielle qui n’a rien à voir avec les signaux. Vous savez que sur les systèmes d’exploitation modernes, vous pouvez allouer plus de mémoire que le système actuel. Alors, comment ça marche ? Eh bien, cela fonctionne en exploitant les interruptions matérielles. Lorsque vous allouez de la mémoire, le kernel 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 kernel ira chercher dans ses notes, trouvera que vous avez effectivement demandé cette mémoire, efface la mémoire dont il dispose gratuitement et demande au processeur de “mapper” cette mémoire à l’emplacement prévu. Après quoi, le kernel reprend votre programme juste avant que l’interruption matérielle ne se produise et cette fois, le processus trouvera la mémoire correcte.

Le multitâche est également implémenté en exploitant une interruption matérielle. Tous les pilotes travaillent 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 habituel des démons Linux pour recharger leur configuration sur SIGHUP, aimé et détesté par les administrateurs système partout. Lorsque vous modifiez, par exemple, une configuration Apache, le processus ne commence pas automatiquement à utiliser la nouvelle configuration. Vous pouvez terminer et redémarrer le processus, mais cela signifie que 4 à 5 secondes votre serveur http sera hors d’air. Donc, à la place, vous pourriez “tuer -HUP apache”. Cela va appeler un sous-programme dans le processus apache, ce qui le fera relire son fichier de configuration.

La suspension de processus est implémentée par des signaux (ctrl-z), une interruption de processus (ctrl-c), une fermeture 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, bien sûr, le matériel demandant l’attention, et le logiciel de niveau le plus bas oblige. Généralement, le kernel gère tout le matériel, et les processus d’information sont quelque peu indépendants 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 l’implémentation dépend beaucoup de l’application (par exemple, SIGHUP).

En ce qui concerne les signaux, ceux-ci ne sont que des logiciels. Ils font tout ce que vous voulez qu’ils fassent, et Linux fournit des méthodes pratiques pour appeler ces sous-routines. Dans certains cas, le kernel peut appeler une routine de signal (par exemple, SIGSEGV, SIGCHILD, …), mais cela n’implique pratiquement pas de matériel. Ils sont juste un moyen pratique de déclencher une routine spécifique dans une application.

Il y avait un cas spécial: l’interruption “OS”, sous 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 kernel 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, le kernel est toujours la source d’un signal (sauf s’il est utilisé pour IPC)

Un signal provient soit du processus lui-même (SIGABRT), du kernel (SIGSEGV, …) ou d’autres processus, comme le shell par exemple (ctrl-z, ctrl-c, ctrl- \, …) ou de tuer. Mais ils peuvent provenir de tout autre programme en utilisant la fonction kill libc:

#include  #include  int kill(pid_t pid, int sig); 

Différence entre le gestionnaire de signaux et les ISR?

La principale différence est que les ISR vivent dans l’espace kernel et doivent prendre en compte le fait que l’ordinateur entier est gelé pendant leur exécution. Cela signifie qu’ils peuvent avoir interrompu tout processus et tout élément du kernel. Ils “arrêtent aussi le monde”. Pendant qu’une interruption est en cours de traitement, rien ne se passera. Donc, si un gestionnaire d’interruption attend quelque chose, la machine se fige. Si un gestionnaire d’interruption passe en boucle, votre seule option est de redémarrer l’ordinateur.

Les ISR sont vraiment difficiles à obtenir. Il y a beaucoup de théorie à leur sujet: sur Linux, ils ont des demi-sections supérieure et inférieure, avec toutes sortes de gestion des priorités, une allocation de mémoire spéciale, et c’est un champ de mines. Un pas dans la mauvaise direction dans un ISR va tuer la machine. Un bogue dans un ISR provoquera un transfert de données, voire une défaillance matérielle totale. En fait, par expérience, le simple fait de soupçonner que vous prévoyez de faire quelque chose de mal dans une ISR entraîne immédiatement un comportement complètement imprévisible de la machine.

Vous ne pouvez utiliser aucune fonction du kernel dans les ISR. Ouvrir un fichier, oubliez-le. Allouer de la mémoire, oublie ça. En appelant n’importe quelle autre partie du kernel, oubliez-la (avec quelques exceptions, 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 empêchera le processus d’avancer, mais par exemple, votre session shell réagira toujours. Le processus doit prendre en compte le fait que toute partie du programme peut avoir été interrompue, bien sûr, mais que l’espace utilisateur rest 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 des interruptions?

Ils sont assez similaires. Sauf que le blocage du signal est effectué par processus. Dans les deux cas, il existe des signaux non bloquables et une NMI (interruption non masquable) (les deux indiquent des erreurs graves).

En fin de compte, les signaux et les interruptions envoient un numéro, soit au kernel, soit à un processus spécifique. Le blocage de signal et le masquage d’interruption signifient simplement dire au système d’ignorer des nombres 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.

Certaines erreurs sont signalées par le processeur comme une exception, puis mappées sur un signal fourni au processus par le kernel. Le kernel peut choisir de masquer toute exception au processus (par exemple, les access à la mémoire non mappée sont silencieusement réparés par la pagination).

Les interruptions matérielles sont simplement une sorte d’exception, que le kernel peut choisir d’associer à un signal (par exemple, si vous utilisez une alarm(2) ).

Le kernel génère des signaux en réponse à divers événements, parmi lesquels des exceptions, l’achèvement des E / S, des requêtes d’espace utilisateur explicites, …

Les gestionnaires de signaux se comportent de la même manière que les ISR – ils peuvent être invoqués à tout moment, de sorte qu’ils ne peuvent émettre aucune hypothèse sur l’état du programme, tout comme les ISR – et bloquer les signaux sur la machine physique.