Processus, mémoire et threads

Modèles pédagogiques créés à partir de S03/S04/S06. P et F sont des identités symboliques, sans PID ni durée réels; M, A, B et C désignent des threads. Chaque clic est une étape logique indivisible du modèle. Aucun noyau, programme C, code utilisateur ou interpréteur n’est exécuté. Créations et attentes réussissent; seul le guide « Exec échoué » injecte cet échec.

Fork crée F, avec retour symbolique F dans P et 0 dans F. Deux espaces d’adressage logiquement indépendants contiennent initialement value=5. La copie sur écriture peut partager des pages physiques protégées; elle ne partage pas les écritures ordinaires. Wait attend puis récolte un statut, même après une fin anormale; il ne fusionne pas les mémoires. Un fils terminé sans statut récolté est zombie : ses données d’exécution ont été libérées.

Exec réussi conserve l’identité et la parenté, remplace code, données, tas et pile, et démarre au point d’entrée du nouveau programme. Aucun retour dans l’ancienne image. Ici l’outil démarre avec une globale pédagogique à 100. En échec, exec retourne −1 et conserve l’ancienne image; ce guide termine alors avec statut 1. Les descripteurs 0/1/2 sont supposés ouverts, hérités et sans close-on-exec : ils restent ouverts au remplacement, puis sont fermés à la fin du processus. Leur état interne et les E/S ne sont pas simulés.

Les threads partagent code, globales a/b, tas et descripteurs du même processus. Chacun possède pile, registres et compteur d’instruction propres. Une pile propre appartient au même espace d’adressage : elle n’est pas protégée contre les autres threads. A reçoit un argument stable 15, B reçoit 2; ils écrivent des variables distinctes. Les joins imposent A fini et B fini avant la création de C, puis C fini avant la lecture finale par M. Join ne protège pas des accès concurrents à une même variable; voir la simulation de concurrence et le contre-exemple S06 §6.6.

Le numéro d’instruction est un index du parcours pédagogique, pas une adresse machine. Après exec réussi, la prochaine instruction appartient à l’outil, à son point d’entrée symbolique.

Les sorties sont des messages abstraits indivisibles, sans tampon stdio ni duplication d’un tampon antérieur à fork. Dans les guides exec : P puis F:outil (ou F:erreur), ou l’inverse; P:fin vient après les deux. Dans le guide threads : A:20 et B:7 peuvent permuter, puis C, puis M:20,7. Le guide de copie affiche seulement P:5. Ces ensembles supposent une exécution complète, sans signal ni autre erreur, avec sélection des acteurs prêts; aucune équité ni terminaison spontanée n’est promise.

1. Fork : attendre puis lire sa copie

   value = 5; fork();
   F : value += 15; terminer;
   P : wait(F); afficher(value); terminer;

   Après la fin du fils et wait, quelle valeur P affiche-t-il? P affiche 5. F a porté sa copie à 20; wait récupère son statut, sans recopier sa mémoire.

2. Fork : fils déjà terminé au wait

   Même programme que le guide précédent.
   Cette fois F termine avant le premier wait de P.

   F est déjà terminé. Le wait de P doit-il attendre un nouveau fils? Non. Le statut de F est disponible : wait le récolte immédiatement. Sans enfant à récolter, wait échouerait; il ne guetterait pas une création future (S06 §6.2).

3. Exec réussi : remplacer sans créer

   fork();
   P : afficher P; wait(F); afficher P:fin; terminer;
   F : exec(outil); // succès : aucun retour ici
   outil : afficher F:outil; terminer(0);

   Combien de processus existent après le remplacement réussi dans F? Deux : P et F. F garde son identité et son parent, mais reçoit une nouvelle image. Le code qui suit exec dans l’ancien programme ne reprend pas.

4. Exec échoué : conserver le programme

   Même père que précédemment.
   F : exec(outil); // échec injecté : retour −1
       afficher F:erreur; terminer(1);

   Un exec échoué remplace-t-il la mémoire de F? Non. Le retour −1 conduit ici à la branche d’erreur de l’ancienne image. F termine avec le statut 1; le retour de wait ne prouve pas sa réussite.

5. Threads : mémoire commune, A/B puis C

   a = 5; b = 5;
   M : créer A(arg=15); créer B(arg=2);
       join(A); join(B); créer C; join(C);
       afficher a,b; terminer le processus;
   A : a = 5 + arg; afficher A:20; terminer le thread;
   B : b = 5 + arg; afficher B:7; terminer le thread;
   C : afficher C; terminer le thread;

   Quel ordre de messages est permis pour les travailleurs? A/B ou B/A, puis C : M joint A et B avant de créer C. Ils écrivent des variables distinctes a/b; join garantit leur fin, sans transformer un accès concurrent en section critique.

Copie avec attente bloquée : fork → P attend → F écrit 20 → F termine, sa mémoire est libérée → P prêt récolte le statut → P affiche 5 → P termine. Variante : F termine avant wait; le statut est disponible sans blocage.

Exec réussi : fork → P affiche et attend → F remplace son image → l’outil affiche → F termine → P récolte le statut 0 → P affiche sa fin et termine. En échec, F conserve son image, affiche l’erreur et termine avec statut 1.

Threads : M crée A puis B et attend A. B peut écrire b=7 et terminer avant A. A écrit a=20 puis termine; M joint A puis B, crée C et attend C. C affiche puis termine. M joint C, lit 20/7 et termine le processus. Les ressources de fin des travailleurs joignables subsistent jusqu’aux joins; aucune pile libérée ne demeure dessinée comme active.

• semaine-03 — 5.2 Trace représentative
• semaine-03 — 5.3 `exec*()`
• semaine-03 — 5.4 `wait()` et `waitpid()`
• semaine-03 — 6. Mémoire après `fork` et copie sur écriture
• semaine-03 — 7. Terminaison, zombies et orphelins
• semaine-04 — 2.2 Le thread comme flot d’exécution
• semaine-04 — 5.3 Lire une trace correctement
• semaine-06 — 6.2. ExempleFork.cpp : attendre avant et après la création
• semaine-06 — 6.5. Question 2 : attendre ne fusionne pas la mémoire de fork
• semaine-06 — 6.6. Question 3 : graphe de threads et compteur sans protection

Maîtres historiques aux omissions déclarées; aucune intégration de S07.