Exercice Corrigé Gestion Des Processus Linux – Partie 3

• (A) Faux: Si P n’a pas de fils zombies, l’appel système wait ne peut pas retourner immédiatement, car il doit attendre un fils non terminé. S’il n’y a pas de fils, il peut y avoir un comportement spécifique selon l’implémentation, mais en général, l’appel ne retourne pas immédiatement.
• (B) Faux: L’appel système wait ne bloque pas toujours P; cela dépend de la présence de fils non terminés.
• (C) Vrai: Si P a exactement un processus fils et que ce fils n’est pas encore terminé, alors l’appel système wait bloquera P.
• (D) Faux: wait ne récupère qu’un seul fils zombie à la fois.

Donc, en effet, seule l’affirmation (c) est vraie.

(a) P retourne immédiatement. Ne bloque pas. S’il n’y a pas d’enfants, wait n’a rien à attendre.

(b) Bloque. Comme l’enfant est toujours en cours d’exécution, wait bloque P jusqu’à ce que cet enfant se termine.

(c) P retourne immédiatement. Ne bloque pas. Si l’enfant est un zombie, wait peut le récupérer et retourne immédiatement.

(d) P retourne immédiatement. Ne bloque pas. wait récupérera l’enfant zombie terminé et ne bloquera pas, même s’il y a un autre enfant en cours d’exécution.

Différentes variantes de l’appel wait (comme wait, waitpid avec des options) peuvent avoir des comportements différents. Par exemple, waitpid peut être utilisé avec l’option WNOHANG, qui permet au parent de ne pas se bloquer s’il n’y a pas d’enfants terminés. Donc, le blocage dépend de la variante utilisée et des options passées.

Les autres affirmations ne sont pas toujours vraies:

• (A) Faux: Le parent ne se bloque pas toujours.
• (B) Faux: Le parent peut se bloquer.
• (C) Vrai seulement dans le cas où le parent utilise wait sans options, mais ce n’est pas toujours vrai pour toutes les variantes de wait.

Ainsi, (D) est la seule affirmation qui est toujours vraie.

• fork: L’interpréteur de commandes crée un nouveau processus en utilisant fork. Cela crée un processus enfant qui va exécuter la commande sleep 100.
• exec: Le processus enfant remplace son image avec celle de la commande sleep en utilisant exec.
• wait: Le processus parent (le shell) attend que le processus enfant se termine en invoquant wait.

Donc, l’ordre correct des appels système est fork, puis exec, et enfin wait.

Lorsqu’un processus lance l’appel système exec, les informations suivantes dans le PCB (Process Control Block) sont modifiées:

• (B) Les entrées de la table des pages: L’appel exec remplace l’image du processus en mémoire, ce qui peut entraîner des modifications dans la table des pages pour refléter les nouvelles pages de mémoire associées à l’exécutable chargé.
• (C) La valeur du compteur de programme: La valeur du compteur de programme (PC) est également mise à jour pour pointer vers le début du nouvel exécutable, car l’exécution commence à partir de ce point.
• (A) L’identifiant du processus (PID): Le PID reste inchangé. L’appel exec ne crée pas un nouveau processus ; il remplace simplement le contenu du processus existant.

En résumé, les entrées de la table des pages et le compteur de programme sont modifiés, mais l’identifiant du processus reste le même.

• (a) L’identifiant du processus => Non identique. Chaque processus a un identifiant unique (PID). Le parent et l’enfant auront donc des PID différents immédiatement après l’exécution de fork.
• (b) Le contenu de la table des descripteurs de fichiers => Identique. Le contenu de la table des descripteurs de fichiers est copié lors de l’appel à fork. Le parent et l’enfant partagent les mêmes descripteurs de fichiers au début, ce qui signifie que les descripteurs de fichiers ouverts sont identiques pour les deux processus.

Lorsque P4 se termine, c’est le processus init qui doit attendre et récupérer P4. Quand P3 se termine, il laisse P4 en tant qu’orphelin, puisque son parent (P3) n’est plus en cours d’exécution. Les processus orphelins sont adoptés par le processus init, qui est responsable de la récupération des processus terminés.

Analysons le code donné pour déterminer le nombre d’enfants directs et d’autres descendants créés :

1. Premier appel fork() :

   • Cela crée un premier enfant, disons P1. À ce stade, nous avons :
     • P (parent)
     • P1 (enfant direct de P)

2. Deuxième appel fork() :

   • Ce fork() est exécuté par deux processus : P et P1.
   • P crée un nouvel enfant, disons P2.
   • P1, qui est déjà en cours d’exécution, crée également un nouvel enfant, disons P3.

Après ces deux appels fork(), nous avons :

• Enfants directs de P :
  • P1 (créé par le premier fork())
  • P2 (créé par le deuxième fork() exécuté par P)

Cela donne donc deux enfants directs de P.

• Autres descendants de P :
  • P3 est un enfant de P1, donc P3 est un descendant de P, mais pas un enfant direct.

Résumé :

• (a) Vrai : Deux enfants directs de P sont créés (P1 et P2).
• (b) Faux : Quatre enfants directs ne sont pas créés.
• (c) Faux : Un autre descendant de P est créé (P3).
• (d) Vrai : Un autre descendant de P (P3) est créé.

Donc, les bonnes réponses sont (A) et (D).

• (A) Vrai: Dans ce contexte, l’ordonnanceur ne préempte pas un processus en cours d’exécution ; il laisse chaque processus s’exécuter jusqu’à ce qu’il se bloque ou se termine. Cela correspond à un comportement non préemptif.
• (B) Vrai: Étant donné que les processus de priorité plus élevée peuvent constamment préempter les processus de faible priorité, ces derniers peuvent ne jamais obtenir l’accès au processeur, ce qui peut entraîner l’inanition.
• (C) Faux: Les processus avec des priorités plus faibles peuvent être défavorisés par rapport à ceux avec des priorités plus élevées, ce qui n’assure pas l’équité.
• (D) Faux: Bien que l’ordonnancement basé sur la priorité puisse réduire le temps d’attente pour des processus de haute priorité, cela ne garantit pas le délai d’exécution moyen le plus court pour tous les processus, en particulier ceux de faible priorité.

Analysons chaque affirmation concernant cette politique d’ordonnancement:

• (a) Vrai: Pour que l’ordonnanceur puisse forcer un changement de contexte après un maximum de 10 millisecondes, il a besoin de la prise en charge des interruptions temporisées. Cela permet de s’assurer que le système d’exploitation peut interrompre un processus en cours pour passer à un autre.
• (b) Faux: Cette politique est un exemple de politique d’ordonnancement préemptive, car elle peut interrompre un processus après un quantum de temps (10 millisecondes) pour passer à un autre processus.
• (c) Vrai: Les changements de contexte peuvent se produire lorsque le quantum de temps est atteint, même si le processus n’est pas bloqué ou terminé. Cela est caractéristique du round-robin.
• (d) Faux: Le round-robin n’implique pas de priorisation des processus en fonction de leur durée d’exécution; chaque processus reçoit un quantum de temps fixe (10 millisecondes) de manière équitable.

Analysons chaque affirmation concernant la sauvegarde du contexte d’exécution du CPU:

• (a) Vrai: Lorsqu’un processus effectue un appel système, le contexte (valeurs des registres, etc.) est sauvegardé sur la pile du noyau afin que le système d’exploitation puisse gérer la demande et restaurer l’état du processus par la suite.
• (b) Vrai: Lors d’un appel de fonction en mode utilisateur, le contexte est généralement sauvegardé sur la pile utilisateur, car la fonction peut avoir besoin d’accéder à l’état précédent du processus.
• (c) Faux: Lors d’un appel de fonction en mode noyau, le contexte est sauvegardé sur la pile du noyau, pas sur la pile utilisateur.
• (d) Vrai: Comme mentionné précédemment, lors d’un appel de fonction en mode noyau, le contexte est sauvegardé sur la pile du noyau.

• (a) Pile utilisateur: Lors d’un appel de fonction en mode utilisateur, le contexte est sauvegardé sur la pile utilisateur.
• (b) Pile du noyau: Lors d’un appel de fonction en mode noyau, le contexte est sauvegardé sur la pile du noyau.
• (c) Pile du noyau: Lors d’un appel système, le contexte est également sauvegardé sur la pile du noyau.
• (d) Pile du noyau: Lorsque le planificateur prend le contrôle, le contexte est sauvegardé sur la pile du noyau, car cela implique un changement de contexte.

Analysons chaque affirmation concernant un changement de contexte:

• (a) Faux: Un changement de contexte ne se produit pas simplement en passant du mode utilisateur au mode noyau. Un changement de contexte implique un changement entre deux processus, ce qui n’est pas nécessaire lors d’un simple appel système.
• (b) Vrai/Faux: Dans le cas des ordonnanceurs préemptifs, un trap (qui inclut les interruptions et les appels système) peut entraîner un changement de contexte si le processus en cours doit céder le contrôle à un autre processus.
• (c) Vrai: Lorsqu’un processus effectue un appel système bloquant, il doit libérer le processeur, ce qui entraîne un changement de contexte pour permettre à un autre processus d’exécuter, qu’il soit préemptif ou non.
• (d) Vrai: Dans un système non préemptif, un processus ne sera pas interrompu tant qu’il ne se bloque pas ou ne termine pas, ce qui signifie qu’il peut continuer à s’exécuter sans être exclu du contexte.

• (a) Lorsqu’un processus effectue un appel système, il utilise une instruction spécifique (comme un « trap » ou un « syscall ») qui est conçue pour déclencher une interruption. Cette instruction contient généralement un numéro d’appel système, qui est utilisé par le noyau pour déterminer quelle fonction doit être exécutée. L’adresse de l’instruction du noyau est définie par le système d’exploitation, et lors de l’exécution de l’instruction de trap, le processeur bascule en mode noyau et redirige l’exécution vers une adresse préalablement configurée dans la table des vecteurs d’interruption.
• (b) Lors de la transition du mode utilisateur au mode noyau, le contexte de l’espace utilisateur (y compris le compteur de programme et d’autres registres) est sauvegardé sur la pile du noyau. Cela permet au système d’exploitation de restaurer cet état lorsque le processus revient en mode utilisateur après avoir terminé l’appel système ou lorsque le processus est planifié à nouveau.

• (a) Réponse: non. L’invocation d’une fonction dans une bibliothèque de l’espace utilisateur ne nécessite pas un passage au mode noyau. Le processus reste en mode utilisateur.
• (b) Réponse: oui. L’appel système kill entraîne un passage au mode noyau, car il nécessite l’interaction avec le noyau pour gérer les signaux et les processus.