Unix:Problème de synchronisation des processus
Bonjour,
Je trouve une difficulté à faire cet exercice:
Considèrons l'arbre des processus (voir image attachée)
Voila le programme que j'ai proposé pour créer l'arbre:
if ( fork()!=0)
if ( fork()!=0)
if ( fork()!=0)
{ fork(); }
On veut modifier ce programme pour que chaque processus Pi exécute une tache Ti avec 1<=i<=4.
Le père doit attendre la terminaison de ses fils avant de se terminer.
J'espère que vous pouvez m'aider Merci.
Je ne comprends pas bien tes "if (fork() ..."
Comment récupères-tu le pid?
C'est ça le problème? Un wait dans le père devrait suffire.Le père doit attendre la terminaison de ses fils avant de se terminer.
A+
Dernière modification par Jack ; 10/06/2014 à 20h47.
il y a une commande qu'il faut connaître: man
(pas trop dur, les 3 premières lettres de manuel)
ensuite il faut un tout petit peut connaître la classification de l'aide:
1 les commandes shell (les programmes en gros)
2 les appels système (fork, open, write, close, ...)
3 les fonctions plus élaborées (fprintf, ...)
4 les devices (et petits trucs associés)
5 les fichiers de config
6 les programmes de jeu
7 les trucs divers et variés
8 les programmes plus système qu'utilisateur
on trouve tout ça dans /usr/share/man/
donc si on fait man fork,
on voit entre autre:
ce serait bien de stocker ça pour la suite...RETURN VALUE
On success, the PID of the child process is returned in the parent, and
0 is returned in the child. On failure, -1 is returned in the parent,
no child process is created, and errno is set appropriately.
et puis vers la fin il y a LE morceau à ne pas louper:
tout manuel bien fichu comporte un "SEE ALSO"...SEE ALSO
clone(2), execve(2), setrlimit(2), unshare(2), vfork(2), wait(2), dae‐
mon(3), capabilities(7), credentials(7)
et comme wait, ça veut en gros dire attendre, c'est man 2 wait qu'il faudra faire...
Jusqu'ici tout va bien...
Re,
On fait le "if ( fork()!=0)" pour créer le fils et revenir à l'état père pour créer les autres fils.
La solution de ce problème se fait avec des wait() mais je n'ai pas réussi à le faire.
On récupère le pid du fils avec la primitive getpid() et le pid du père avec getppid() voila comment:
printf("fils:%d père:%d\n",getpid(),getppid()) ;
Je trouve plus simple de récupérer le pid lors de l'appel de forkEnvoyé par Sarappele
Tu as bien lu la doc et relevé ce que renvoie la fonction wait?
Pour quoi faire ? On peut attendre la fin de tous les fils sans connaitre leurs PID, en insérant le code suivant dans le père, juste avant de quitter:
Code:int status; while (wait(&status)>0);
Encore faut-il savoir qu'on est dans le processus père.
Je trouve logique de récupérer le pid renvoyé par chaque appel de fork afin de savoir si on est dans le père, dans le fils ou si la création du processus a avorté.
A+
C'est justement l'intéret des "if ( fork()!=0[...] ": détecter si on est dans le pere, fork() renvoyant 0 si on est dans le fils. Et on n'a pas besoin de stocker la valeur de retour; elle ne nous est d'aucune utilité s'il s'agit juste d'attendre la fin de tous les fils.
Dans le code présenté, ces "if" sont imbriqués pour etre sur que c'est bien toujours pere qui forke, et pas les fils. Bien sur, il faut encore modifier un dernier petit truc pour résoudre le problème, mais si je l'ecris ici je donne la soluce; laisse le chercher un peu
Dernière modification par Garlik ; 11/06/2014 à 17h20.
Et si le fork avorte, on le sait comment?
Si le fork() avorte, le fils n'est pas créé mais le père continue, lui. Ça ne change rien pour ce dernier; même si seulement 3, 2 (ou même 0 !) fils sont créés avec succès, on sortira de toute façon du "while(wait());" lorsque tous les fils seront terminés, fork() avorté ou pas, et quels qu'en soient le nombre. C'est toute l'élégance du procédé.
Alors, oui, on peut tester les valeurs de retour de chacun des forks(), et se lancer dans une programmation complexe avec autant de wait() que de fils réellement crées, tout en mettant en place un mécanisme élaboré de traitement des erreurs... Je conçois que c'est intellectuellement satisfaisant, mais ça alourdit inutilement le code, sans en améliorer le fonctionnement, et on prend le risque de se tromper dans l'implémentation de l'algorithme en oubliant des cas de figure.
Bref, je dis juste qu'il ne sert à rien de stocker une valeur si on ne s'en sert pas.
Sinon, deux petites corrections qui m'avaient échappées;
1) il est aussi inutile de fournir une adresse d'argument pour wait() puisqu'on se fout du statut d'erreur. Un wait(0) suffit donc amplement.
2) Jouons un peu: le bon code c'est
et pasCode:while(wait(0)!=-1);
Ami lecteur, et amateur de langage C, saurais expliquer pourquoi ?Code:while(wait(0));
Dernière modification par Garlik ; 12/06/2014 à 10h30.
Je ne vois pas l'intérêt de faire un wait si aucun fils n'a été créé. Quant à la "lourdeur" de la gestion du pid, il ne semble pas si rédhibitoire de gérer 3 cas: père, fils, erreur.
Dernière modification par Jack ; 12/06/2014 à 20h02.
Dans ce cas 'ie pas de fils), le wait() n'est pas bloquant, et il renvoie -1 immédiatement. Dans mon exemple, ça permet d'éviter de traiter le code de retour de fork() et de s'affranchir d'une gestion lourdingue d'erreur dont on ne fait rien au final. Et d'autant plus lourdingue qu'il existe de processus forkés.
De façon plus générale, on ne traite pas un code de retour si on n'a pas l'intention d'en faire quelque chose d'utile, comme retenter l'appel une seconde fois ou transférer le contrôle sur un mode dégradé. En l’occurrence, et pour le besoin de cet exercice, ce code de retour ne nous sert pas, il est donc inutile de mettre en place un quelconque traitement.
une affectation, lourdingue, c'est un peu exagéré. D'autant plus qu'on ne sait pas si ça ne peut pas servir dans le fils.
En fait c'est devenu un automatisme, un peu comme mettre sa ceinture de sécurité.
Dans ce cas précis qui me semble minimaliste, on peut en effet s'en passer.
