Exercice Corrigé Gestion Des Processus Linux – Partie 2

Cependant, il est possible que certains segments de mémoire, comme les bibliothèques partagées, soient partagés entre plusieurs processus. Cela signifie que certaines parties du code peuvent être utilisées par plusieurs processus, mais chaque processus maintient sa propre copie des données et de l’état d’exécution.

P1 est cours d’exécution. P2 est prêt

• Processus P1: Lorsque l’interruption de disque se produit, P1 passe en mode noyau pour gérer l’interruption. Après l’exécution de la routine de service d’interruption, P1 est prêt à retourner en mode utilisateur. Cependant, il est en train de gérer l’interruption, donc P1 est bloqué tant qu’il est en mode noyau. Une fois que le système d’exploitation termine la gestion de l’interruption et que P1 revient au mode utilisateur, il passe à l’état en cours d’exécution (s’il a été sélectionné par le planificateur pour continuer son exécution).
• Processus P2: Pendant l’interruption, la routine de service a débloqué P2, qui avait été bloqué lors de la lecture du disque. Maintenant que l’interruption est traitée et que les ressources sont disponibles, P2 est maintenant prêt à s’exécuter, car il peut maintenant être planifié pour s’exécuter par le système d’exploitation.

Voici des exemples pour chaque type de changement de contexte:

(a) Changement de contexte volontaire:

Un processus demande une opération d’E/S, comme lire un fichier, ce qui entraîne un changement de contexte.

(b) Changement de contexte involontaire:

Un processus atteint la fin de son quantum de temps alloué, et le système d’exploitation le suspend pour permettre à un autre processus de s’exécuter.

(a) Non: C ne devient pas immédiatement un zombie. Il reste un processus en cours d’exécution et sera adopté par le processus init (ou un processus similaire) lorsque son parent P se terminera.

(b) Non: P ne devient pas un zombie. Un processus zombie est un processus dont l’exécution est terminée mais qui n’a pas été récupéré par son parent. Puisque P se termine normalement, il ne devient pas un zombie.

Vrai. Un processus en mode utilisateur ne peut pas exécuter certaines instructions matérielles privilégiées, car ces instructions sont réservées au mode noyau. Cela protège le système d’exploitation et les ressources critiques contre les actions non sécurisées ou non autorisées des processus utilisateurs.

(a) Privilégiée: L’instruction d’écriture dans le registre de la table des descripteurs d’interruption est privilégiée, car elle modifie la façon dont le système gère les interruptions. Si cette instruction était exécutée en mode non privilégié, un processus utilisateur pourrait altérer la gestion des interruptions, entraînant un comportement imprévisible du système et potentiellement permettant une élévation de privilèges.

(b) Non privilégiée: L’instruction d’écriture dans un registre d’usage général de l’unité centrale de traitement est non privilégiée, car elle n’affecte que l’état du processus en cours sans impact sur le système d’exploitation ou sur d’autres processus. Cela permet aux programmes utilisateurs d’effectuer des calculs et des opérations sans compromettre la sécurité ou la stabilité du système.

• system: Ne correspond pas à une invocation directe d’appel système. La fonction system exécute une commande dans l’interpréteur de commandes, ce qui implique généralement plusieurs étapes, comme le fork et l’exécution d’un shell, plutôt qu’un simple appel système direct.
• fork: Correspond à un appel système. La fonction fork est une invocation directe de l’appel système fork, qui crée un nouveau processus enfant.
• exit: Correspond à un appel système. La fonction exit appelle en réalité l’appel système exit pour mettre fin au processus en cours, même si elle peut effectuer des opérations supplémentaires comme l’exécution de fonctions de nettoyage.
• strlen: Ne correspond pas à une invocation directe d’appel système. La fonction strlen est une opération de bibliothèque qui calcule la longueur d’une chaîne en mémoire et n’effectue pas d’appels systèmes. Elle opère entièrement en mode utilisateur sur des données en mémoire.

• (b) Un appel système bloquant: Cela entraîne un changement de contexte, car le processus se met en attente et le système d’exploitation doit passer à un autre processus prêt à s’exécuter.
• (c) L’appel système exit: Cela entraîne également un changement de contexte, car le processus se termine et doit être retiré de la planification.

Les actions (b) et (c) entraîneront un changement de contexte même dans un noyau non préemptif.

Faux: Étant donné que les deux systèmes d’exploitation sont compatibles POSIX, le code source d’une application conçue pour fonctionner sur la machine A ne nécessite pas nécessairement une réécriture complète pour fonctionner sur la machine B. La compatibilité POSIX garantit un certain niveau d’uniformité dans l’interface des appels système et des fonctions de la bibliothèque standard, ce qui facilite la portabilité du code entre différentes architectures et systèmes d’exploitation. Cependant, des ajustements peuvent être nécessaires pour des aspects spécifiques à l’architecture ou à des fonctionnalités non standard.

Vrai: Une application binaire compilée pour la machine A devra généralement être recompilée pour s’exécuter correctement sur la machine B, même si les deux systèmes d’exploitation sont compatibles POSIX. Les différences d’architecture (comme l’architecture du processeur, les instructions spécifiques, les tailles de données, etc.) signifient que le binaire compilé pour A ne sera pas directement exécutable sur B sans recompilation.

Il s’agit d’un changement de contexte involontaire.

Justification: Le processus se bloque en attendant que le paquet soit disponible, et ce blocage est généralement causé par l’appel système. Le planificateur, en réponse à ce blocage, doit choisir de passer à un autre processus pour maximiser l’utilisation des ressources. Cela se fait sans que le processus d’origine ait explicitement décidé de céder le contrôle, ce qui en fait un changement de contexte involontaire.

Faux: Un changement de contexte peut se produire non seulement après le traitement d’une interruption de temporisation, mais aussi après d’autres appels système ou interruptions. Par exemple, si un processus effectue un appel système et se bloque en attendant des ressources (comme une lecture de fichier ou un accès réseau), le planificateur peut choisir de changer de contexte pour permettre à un autre processus de s’exécuter. Les interruptions matérielles, telles que celles provenant de périphériques, peuvent également entraîner un changement de contexte lorsque le système d’exploitation décide de passer à un autre processus.

Faux: Bien qu’il soit vrai que les programmes C utilisent généralement la bibliothèque C pour invoquer des appels système, il est en effet possible d’invoquer directement ces appels à partir du code utilisateur, bien que cela soit plus complexe et nécessite une connaissance approfondie de l’architecture du système. Les appels système peuvent être appelés directement via des mécanismes comme les interruptions ou les instructions spécifiques, mais cela n’est pas courant en raison de la complexité et des implications en termes de portabilité.

Faux: Un processus ne subit pas nécessairement un changement de contexte chaque fois qu’il passe du mode utilisateur au mode noyau. Le changement de contexte implique un changement entre deux processus ou threads différents, ce qui inclut la sauvegarde de l’état d’un processus et le chargement de l’état d’un autre. Lorsque le contrôle passe du mode utilisateur au mode noyau, cela peut se faire sans changer le processus en cours d’exécution, par exemple lors d’un appel système. Dans ce cas, le même processus continue de s’exécuter, et il n’y a pas de changement de contexte.