Exercice Corrigé Gestion Des Processus Linux – Partie 5

Voici comment vous pouvez modifier le code pour rediriger la sortie vers file.txt en utilisant close et open:

command = read_from_user();
int rc = fork();

if (rc == 0) { // child
    close(STDOUT_FILENO); // Fermer STDOUT
	// Ouvrir file.txt pour écriture
    open("file.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); 
    exec(command); // Exécuter la commande
} else { // parent
    wait();
}

Les composantes du contexte de système de fichiers d’un processus sous Linux sont:

• close(STDOUT_FILENO);: Ferme le descripteur de sortie standard.
• open("file.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);: Ouvre (ou crée) file.txt en mode écriture. Les options signifient:
  • O_WRONLY: Ouverture en écriture seule.
  • O_CREAT: Crée le fichier s’il n’existe pas.
  • O_TRUNC: Truncate le fichier à 0 octets si le fichier existe déjà.
• exec(command);: Exécute la commande, et la sortie ira vers file.txt.

Avec ces changements, la sortie de la commande exécutée dans le processus enfant sera redirigée vers file.txt.

Le programme affichera:

child
parent

Dans l’extrait de code donné, si l’appel système exec échoue, le comportement sera le suivant:

1. Fork : Un nouveau processus (enfant) est créé.
2. Processus enfant (ret == 0) :
   • Tente d’exécuter exec(quelque_binaire_qui_ne_fait_pas_executer).
   • Comme exec échoue, le code suivant dans l’enfant s’exécute.
   • La ligne printf("child\n"); sera exécutée.
3. Processus parent (ret > 0) :
   • Appelle wait(), attendant que l’enfant se termine.
   • Une fois l’enfant terminé, il exécute printf("parent\n");.

(a) Parent attend que l’enfant termine avant de commencer ses tâches

Pour garantir que le processus parent commence l’exécution de ses deux tâches seulement après que le processus enfant ait terminé, vous pouvez utiliser wait(). Voici le code modifié:

int ret = fork();
if (ret == 0) {
    do_child_task(); // Tâche de l'enfant
} else {
    wait(NULL); // Le parent attend que l'enfant se termine
    do_parent_task1(); // Tâche 1 du parent
    do_parent_task2(); // Tâche 2 du parent
}

(b) Parent exécute la première tâche avant l’enfant, puis attend la fin de l’enfant

Pour que le processus parent exécute sa première tâche avant que l’enfant ne commence et n’exécute sa deuxième tâche qu’après que l’enfant ait terminé, vous pouvez utiliser des tubes (pipes) pour synchroniser les processus. Voici un exemple de code modifié:

int pipe1[2], pipe2[2];
pipe(pipe1); // Tube pour synchroniser le parent vers l'enfant
pipe(pipe2); // Tube pour synchroniser l'enfant vers le parent

int ret = fork();
if (ret == 0) {
    close(pipe1[1]); // Ferme l'extrémité d'écriture du tube 1
    read(pipe1[0], NULL, 0); // L'enfant attend un signal du parent
    do_child_task(); // Tâche de l'enfant
    close(pipe2[0]); // Ferme l'extrémité de lecture du tube 2
    write(pipe2[1], NULL, 0); // Signale au parent que l'enfant a fini
} else {
    do_parent_task1(); // Tâche 1 du parent
    close(pipe1[0]); // Ferme l'extrémité de lecture du tube 1
    write(pipe1[1], NULL, 0); // Signale à l'enfant de commencer
    close(pipe2[1]); // Ferme l'extrémité d'écriture du tube 2
    read(pipe2[0], NULL, 0); // Le parent attend que l'enfant termine
    do_parent_task2(); // Tâche 2 du parent
}

Résumé:

• (a) Utiliser wait() pour que le parent attende l’enfant.
• (b) Utiliser des tubes pour synchroniser les tâches entre le parent et l’enfant.

Voici les sorties possibles pour le programme donné, en tenant compte des différents scénarios d’exécution:

Cas I: fork et exec réussissent
Sortie:

Hello1
Hello3

Explication: Le processus enfant affiche « Hello1 » puis exécute quelque_executable. Comme exec réussit, la ligne suivante (printf(« Hello2\n »);) n’est pas exécutée. Le parent attend que l’enfant se termine avant d’afficher « Hello3 ».

Cas II: fork réussit mais exec échoue
Sortie:

Hello1
Hello2
Hello3

Explication: Le processus enfant affiche « Hello1 » mais échoue lors de l’exécution de exec. Il continue donc à exécuter la ligne suivante et affiche « Hello2 ». Ensuite, le parent attend que l’enfant se termine (qui se termine après avoir affiché « Hello2 ») avant d’afficher « Hello3 ».

Cas III: fork échoue
Sortie:

Hello4

Explication: Si fork échoue, le code du parent ne sera pas exécuté, mais le else s’exécute et affiche « Hello4 ». Aucune autre sortie n’est générée.

(a) Réponse: Les deux commandes cmd1 et cmd2 s’exécutent en parallèle. Le processus parent crée un enfant pour cmd1, puis crée un deuxième enfant pour cmd2, et les deux enfants s’exécutent simultanément.

(b) Modifier le code pour l’exécution en série. Pour changer l’exécution des commandes de parallèle à série, il faut que le processus parent attende la fin de cmd1 avant de lancer cmd2. Voici comment modifier le code:

int rc1 = fork();
if (rc1 == 0) {
    exec(cmd1);
} else {
    wait(); // Attendre que cmd1 se termine
    int rc2 = fork();
    if (rc2 == 0) {
        exec(cmd2);
    } else {
        wait(); // Attendre que cmd2 se termine
    }
}

Modifications: Déplacer la première wait() avant le deuxième fork(): Cela garantit que le parent attend que cmd1 se termine avant de créer un processus pour cmd2.

Sortie:

L'enfant 1 a démarré
L'enfant 2 a démarré
(Un message d'erreur provenant du mauvais exécutable)
L'enfant 2 a terminé
Enfant récupéré
Hello from good_executable
Parent terminé

Explication des sorties:

• « L’enfant 1 a démarré » – affiché par Child 1 immédiatement après le fork().
• « L’enfant 2 a démarré » – affiché par Child 2 après la période de sommeil de 10 secondes.
• « (Un message d’erreur provenant du mauvais exécutable) » – généré lorsque Child 2 essaie d’exécuter bad_executable, qui n’existe pas, entraînant une erreur d’exécution.
• « L’enfant 2 a terminé » – affiché après que Child 2 se termine à cause de l’échec de exec.
• « Enfant récupéré » – affiché par le parent après avoir récupéré Child 2.
• « Hello from good_executable » – affiché par good_executable pendant son exécution, mais il apparaîtra après « Enfant récupéré ».
• « Parent terminé » – affiché par le parent après que tous les enfants ont été récupérés.

Comportement du programme

1. Création du tube :

   • pipe(fd) crée un tube avec deux descripteurs :
     • fd[0] pour la lecture.
     • fd[1] pour l’écriture.

2. Fork :

   • fork() crée un processus enfant. Après cet appel, il y a deux processus : le parent (avec rc > 0) et l’enfant (avec rc == 0).

 

Comportement de l’enfant (rc == 0)

• Actions de l’enfant :
  • close(fd[1]) : L’enfant ferme le descripteur d’écriture (fd[1]), car il n’a pas besoin d’écrire dans le tube.
  • printf("child1\n") : L’enfant affiche « child1 ».
  • read(fd[0], bufc, bufc_size) : L’enfant tente de lire depuis le tube. Il attend ici jusqu’à ce que le parent écrive quelque chose dans le tube.

 

Comportement du parent (rc > 0)

• Actions du parent :
  • close(fd[0]) : Le parent ferme le descripteur de lecture (fd[0]), car il n’a pas besoin de lire.
  • printf("parent1\n") : Le parent affiche « parent1 ».
  • write(fd[1], bufp, bufp_size) : Le parent écrit des données dans le tube. Cela réveille l’enfant qui attend de lire.
  • wait() : Le parent attend que l’enfant termine son exécution.
  • printf("parent2\n") : Après que l’enfant se soit terminé, le parent affiche « parent2 ».

 

Scénarios d’exécution

1. Scénario 1 : L’enfant est programmé avant le parent

   • L’enfant s’exécute en premier :
     • Affiche child1.
     • Ferme le descripteur d’écriture et lit depuis le tube. À ce moment, le parent n’a pas encore écrit, donc il attend.
   • Ensuite, le parent s’exécute :
     • Affiche parent1.
     • Écrit dans le tube, ce qui permet à l’enfant de lire et d’afficher child2.
     • Finalement, le parent affiche parent2 après que l’enfant ait terminé.
   • Sortie:

     child1
     parent1
     child2
     parent2

2. Scénario 2 : Le parent est programmé avant l’enfant

   • Le parent s’exécute en premier :
     • Affiche parent1.
     • Écrit dans le tube, ce qui permet à l’enfant de lire lorsqu’il s’exécute.
   • Ensuite, l’enfant s’exécute :
     • Affiche child1.
     • Lit depuis le tube et affiche child2.
   • Enfin, le parent attend que l’enfant se termine et affiche parent2.
   • Sortie :

     parent1
     child1
     child2
     parent2

Résumé des sorties

Ainsi, les deux sorties possibles selon l’ordre d’exécution des processus sont :

1. child1, parent1, child2, parent2 (l’enfant s’exécute d’abord).
2. parent1, child1, child2, parent2 (le parent s’exécute d’abord).

Ces sorties montrent comment l’ordonnancement des processus peut influencer le comportement du programme.

Le code entre dans une boucle while+fork infinie, car chaque processus enfant qui est forké exécutera le même code avec une valeur plus élevée de « a » et donc la boucle while ne se termine jamais. Il y aura un nombre infini de processus enfants qui afficheront a=3,4,5, et ainsi de suite, jusqu’à ce que la fork échoue ou que le système utilise une autre ressource.

Comportement détaillé

1. Boucle infinie :

   • Chaque fois qu’un processus enfant est forké, il incrémente a (qui commence à 2) avant d’afficher sa valeur.
   • Les enfants successifs augmentent a de 1 à chaque fork, entraînant des valeurs de a = 3, 4, 5, etc.

2. Processus parent :

   • Pendant ce temps, le parent décrémente a après avoir attendu la fin de l’enfant, mais à chaque itération, de nouveaux enfants continuent à être créés et à augmenter a.

3. Résultat :

   • La boucle continue indéfiniment, avec une production continue d’enfants qui affichent des valeurs de a croissantes.
   • La sortie affichera des lignes comme:

     a=3
     a=4
     a=5
     ...

   • Cela continuera jusqu’à ce qu’une limite système soit atteinte (comme la limite du nombre de processus) ou que le système rencontre une erreur.

Résumé du Programme

1. Initialisation:

   • int a = 2;: La variable a commence à 2.

2. Boucle while :

   • Tant que a > 0, le programme fork un enfant.

3. Processus Enfant (ret == 0) :

   • Incrémente a (devient 3).
   • Affiche a=3.
   • Exécute execl("/bin/ls"), remplaçant l’enfant par la commande ls.

4. Processus Parent (ret > 0) :

   • Attend que l’enfant se termine.
   • Décrémente a (devient 1 après le premier enfant).

5. Deuxième itération :

   • Fork un nouvel enfant (qui incrémente a à 2, affiche a=2, et exécute ls).

Sortie:

a=3
<sortie de la commande ls>
a=2
<sortie de la commande ls>

Chaque enfant affiche sa valeur avant d’exécuter ls.

Communication et Synchronisation entre le Serveur et les Processus Worker

Pour assurer une communication efficace et une synchronisation entre le processus maître (serveur) et les processus workers, nous pouvons utiliser une combinaison de mémoire partagée et de sémaphores pour gérer l’accès concurrent à la mémoire partagée, ainsi que des mécanismes de notification pour signaler aux workers quand une nouvelle requête est disponible.

1. Structure de la Mémoire Partagée

• Tampon de Requêtes : Une zone de mémoire partagée où le serveur écrit les requêtes. Chaque requête aura une taille fixe pour simplifier la gestion.
• Index : Un index pour suivre la position de la dernière requête écrite et celle lue, afin de gérer le FIFO (First In First Out) des requêtes.

2. Utilisation de Sémaphores

• Sémaphore de lecture/écriture : Utiliser deux sémaphores :
  • Un sémaphore pour contrôler l’accès en écriture, permettant au serveur d’écrire dans le tampon lorsque c’est sûr.
  • Un sémaphore pour contrôler l’accès en lecture, permettant aux workers de lire une requête lorsqu’elle est disponible.

3. Mécanisme de Notification

• Signalisation : Une fois qu’une requête est écrite dans le tampon, le serveur peut envoyer un signal (par exemple, à l’aide de signaux ou d’une variable conditionnelle) à un worker inactif pour l’informer qu’il y a une nouvelle requête à traiter.

4. Processus de Traitement

• Serveur :

  • Récupère les requêtes des clients et les écrit dans le tampon de requêtes.
  • Utilise le sémaphore d’écriture pour s’assurer qu’il n’écrit pas pendant qu’un worker lit.
  • Notifie un worker libre pour commencer à traiter la requête.

• Workers :

  • Attend la notification du serveur pour lire la requête dans le tampon.
  • Utilise le sémaphore de lecture pour garantir un accès sûr au tampon.
  • Une fois la requête traitée, écrit la réponse dans le tampon et utilise une autre notification pour informer le serveur.

5. Équité et Efficacité

• Équité : Pour garantir que tous les workers partagent la charge équitablement, le serveur peut utiliser une stratégie de round-robin pour notifier les workers, leur permettant de prendre des requêtes dans l’ordre où ils sont disponibles.
• Efficacité : En utilisant des sémaphores et des notifications, aucun worker ne reste inactif en attendant des requêtes, réduisant ainsi le temps d’attente pour les requêtes et maximisant l’utilisation des workers.

Conclusion

Cette approche permet de gérer efficacement la communication et la synchronisation entre le serveur et les processus workers, garantissant que chaque requête est traitée par un unique worker, tout en maintenant un système équitable et performant sur un système multicœur moderne.