Multiple fork() en C

**Postgres.0** · 22/10/2011, 14h06

Bonjour,

j'écris ici pour solliciter votre aide, je vais résumer mon problème :

je veux créer n processus fils pour exécuter en parallèle la fonction child_procedure() à chacun des processus fils.
Mais on me demande de lancer que p processus d'abord (p < n), puis dès qu'un processus s’arrête je relance un nouveau, jusqu'à ce que les n soient lancés.

Donc mon code ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
while(i < p)
{
   pid = fork();
   if(pid == 0)
 
    break;
 
  else if( pid = =-1)
  exit(1);
 
}
if(pid >0)
{
while(1){
 if(wait(&status) != -1)
 {
    j++;
    if(j== n) break;
    pid0 = fork()
    if(pid0 == 0)
    {
       child_procedure()
 
      }
 
    }
   else break;
}
 
}
 
else child_procedure();

Mais ça ne marche pas, j'ai mis ici un résume de mon code, j'ai l'impression que quand un fils s’arrête je crée mal le nouveau fils ou bien il n’exécute pas correctement la tache, en tout cas mon programme plante.

Bref, je suis débutant, et si quelqu'un a une idée ingénieuse ou bien du code C écrit déjà, je suis preneur.

Cordialement

**Steph_ng8** · 22/10/2011, 20h16

Bonsoir.

Tes variables i et j représentent quoi ?
Avec quelles valeurs sont-elles intialisées ?
C'est normal que i ne soit jamais modifiée ?

**Steph_ng8** · 22/10/2011, 20h26

Je peux te proposer un algo en pseudo-code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
p_total = 0
p_simult = 0
 
TANT QUE p_total < n FAIRE
    SI p_simult < p ALORS
        nouveau_processus()
        ++p_simult
        ++p_total
    SINON
        attendre()
        --p_simult
    FIN SI
FIN TANT QUE

Au fait, c'est un exercice ?

**Postgres.0** · 24/10/2011, 09h57

Envoyé par Steph_ng8

Je peux te proposer un algo en pseudo-code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
p_total = 0
p_simult = 0
 
TANT QUE p_total < n FAIRE
    SI p_simult < p ALORS
        nouveau_processus()
        ++p_simult
        ++p_total
    SINON
        attendre()
        --p_simult
    FIN SI
FIN TANT QUE

Au fait, c'est un exercice ?

Non, c'est un projet.

ce qui me dérange dans ta solution c'est que les fils ne vont pas s'executer en parallèle.

**Postgres.0** · 24/10/2011, 10h35

J'ai adapté ta solution à mon code, mais j'ai toujours l'impression que ça ne marche pas :

**jeroman** · 24/10/2011, 11h49

Comme cela t'a été demandé plus haut, poste ton code avec la balise CODE prévue à cette effet. C'est illisible.

En outre, ton code n'est pas du C mais du C++.

**Postgres.0** · 24/10/2011, 12h56

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 valueIndex = -1;
   nb_proc_waited =0;
	while(valueIndex < MAX_VALS -1 )
	{             cout <<   "value " << valueIndex << endl;
         if(nb_proc_waited <= maxChildNumber )
          {  valueIndex++; 
             nb_proc_waited++;  
             pids[valueIndex] = pid = fork();
             if (!pid)
             {     
                    g_process_id =  process_id_value[valueIndex];
                    cout <<   "ID :" << getpid() << endl; 
                    cout <<  " process " << g_process_id << endl; 
                    break;
             }
          }   
          else
          {
               if ((cpid=wait(&status)) != -1)
			          nb_proc_waited--;
 
 
          }   
   }           
 
 
 
  if(pid ==0) exec_child();
 else if (pid!=0 && pid!=-1) 
  {  
 
  cout << "BREAK  :" << endl;
           cout << "finish "  << endl;
       delete [] process_id_count;
       delete [] process_id_value;
       delete [] pids; 
    syslog(LOG_INFO, " .......................................Connexion closed") ;
    closelog();          
 
	}

Désolé, je ne connaissais pas cette balise.

**Postgres.0** · 24/10/2011, 13h32

Quand j'exécute ce code le père se termine avant certains fils.

**Steph_ng8** · 24/10/2011, 16h49

Envoyé par Postgres.0

ce qui me dérange dans ta solution c'est que les fils ne vont pas s'executer en parallèle.

Hum, j'ai probablement oublié de préciser que mon algorithme ne concerne que le processus père.
Derrière la « fonction » nouveau_processus(), il y a à la fois le fork(), les tests pour vérifier qu'on est dans le père, le fils, ou si la création de processus a échoué, et le code que doit exécuter le fils.
Code qui doit probablement se terminer avec un exit().

Et alors normalement, les processus fils s'exécutent bel et bien en parallèle.
Enfin sauf si ce qu'on leur demande de faire est trop court...
Après, c'est sûr que mon algorithme ne cherche des fils terminés que lorsque le nombre maximal de fils ont été lancés, qu'ils se soient arrêtés entre-temps ou non...

Envoyé par Postgres.0

Quand j'exécute ce code le père se termine avant certains fils.

Parce qu'il faut penser à attendre tout le monde avant d'arrêter le père...
Je reconnais que c'est un oubli de ma part.
Désolé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
p_total = 0
p_simult = 0
 
TANT QUE p_total < n FAIRE
    SI p_simult < p ALORS
        nouveau_processus()
        ++p_simult
        ++p_total
    SINON
        attendre()
        --p_simult
    FIN SI
FIN TANT QUE
 
TANT QUE p_simult > 0 FAIRE
    attendre()
    --p_simult
FIN TANT QUE

Une solution probablement meilleure, mais plus complexe, serait d'utiliser le compteur de processus actifs simultanément en tant que ressource partagée.
Dans ce cas, le processus père se contenterait de lancer tous les processus fils, puis d'attendre qu'ils soient terminés.
Chaque processus fils commencerait par accéder à la ressource partagée : si elle lui indique qu'il peut s'exécuter, alors il la met à jour (un processus actif de plus !) ; sinon, il se suspend et attend d'avoir l'autorisation de s'exécuter.
À la fin de l'exécution, chaque processus fils met à nouveau à jour la ressource partagée (un processus actif en moins !).

Si ce n'est pas déjà fait, renseigne-toi sur les mutex et les sémaphores.

**Postgres.0** · 24/10/2011, 17h16

L'éxecution de vos processus fils sera sequentielle alors qu'on cherche à avoir une execution paralléle.
J'aurai mis un break; après la création de chaque fils.
Ensuite, executer la fonction par les fils en dehors de la boucle.

Cordialement

**Postgres.0** · 24/10/2011, 17h35

Merci beaucoup, faites pas attention à mon précédent post.

Quelqu'un m'a dit que c'est trop couteux d'attendre la fin des process et de recreer d'autres.

Qu'en pensez vous ?

**Steph_ng8** · 24/10/2011, 17h36

Non, l'exécution sera bien en parallèle.
Encore une fois, du point de vue du père, lorsque l'on arrive à la ligne 6 on passe à la ligne suivante dès que le processus fils est créé (via le fork()).
On n'attend pas qu'il soit terminé.

À moins que quelqu'un connaisse un moyen de lancer plusieurs processus fils exactement en même temps, on est obligé de le faire au travers d'une boucle.
Et leur exécution ne sera séquentielle que si les instructions qu'ils doivent exécuter sont tellement courtes qu'ils se terminent avant la fin de la boucle du père.

**Steph_ng8** · 24/10/2011, 17h52

Si tu ne me crois toujours pas...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
 
 
 
#define MAX_CHILDREN    5
#define MAX_PROCESS     10
#define SLEEP           5
 
 
 
int main()
{
    int children = 0;
    int process = 0;
    pid_t pid;
 
    while (process < MAX_PROCESS) {
 
        if (children < MAX_CHILDREN) {
            pid = fork();
 
            if (pid < 0) {
                perror("fork");
                exit(EXIT_FAILURE);
 
            } else if (!pid) {
                pid = getpid();
                printf("%u: Début du fils...\n", pid);
                sleep(SLEEP);
                printf("%u: Fin du fils.\n", pid);
                exit(EXIT_SUCCESS);
            }
 
            ++children;
            ++process;
            printf("%u: Lancement du fils %u (%d/%d - %d/%d)...\n", getpid(), pid, process, MAX_PROCESS, children, MAX_CHILDREN);
 
        } else {
            pid = wait(NULL);
            --children;
            printf("%u: Fin du fils %u (%d/%d - %d/%d).\n", getpid(), pid, process, MAX_PROCESS, children, MAX_CHILDREN);
        }
 
    }
 
    while (children > 0) {
        pid = wait(NULL);
        --children;
        printf("%u: Fin du fils %u (%d/%d - %d/%d).\n", getpid(), pid, process, MAX_PROCESS, children, MAX_CHILDREN);
    }
 
    return EXIT_SUCCESS;
}

**Postgres.0** · 25/10/2011, 13h10

Merci beaucoup, ça m'a beaucoup aidé.

**Steph_ng8** · 25/10/2011, 14h23

Envoyé par Postgres.0

Merci beaucoup, faites pas attention à mon précédent post.

Quelqu'un m'a dit que c'est trop couteux d'attendre la fin des process et de recreer d'autres.

Qu'en pensez vous ?

Désolé, je n'avais pas vu ce message.
Je n'ai pas de grandes connaissances en ce qui concerne la programmation en parallèle, mais ça me semble logique.
Après tout, lorsque l'on crée un nouveau processus, on duplique une partie de l'environnement !

Ce que j'ai proposé est une solution simple et fonctionnelle, mais pas forcément optimisée, et il y a sûrement mieux à faire en cas d'erreur.
J'ai évoqué plus haut une autre solution à base de sémaphores, plus satisfaisante à mon avis, mais plus complexe à mettre en place.

Pour éviter d'avoir à créer trop de processus, on peut voir une autre approche.
Le processus père lance les p processus fils d'un coup, puis attend qu'ils se terminent.
Entre temps, il leur a mis à disposition une ressource partagée indiquant le nombre de tâches à effectuer.
Chaque processus fils commence par interroger la ressource partagée : s'il reste des tâches à effectuer, il met à jour la ressource (une tâche de moins à faire) et s'exécute ; si toutes les tâches ont été faites, il termine.
Dès qu'un processus fils termine une tâche, il interroge de nouveau la ressource partagée, et ainsi de suite.

De cette manière, on a bien p processus au maximum qui tournent simultanément, et à la fin les n tâches sont exécutées.
Mais qui dit « ressource partagée » dit « mutex ».
Je n'ai pas beaucoup travaillé avec les ressources partagées, alors je peux juste donner le principe.

Code Processus père :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
nb_proc = 0
nb_taches = MAX_TACHES
 
TANT QUE nb_proc < MAX_PROC FAIRE
    nouveau_processus()
    ++nb_proc
FIN TANT QUE
 
TANT QUE nb_proc > 0 FAIRE
    attendre()
    --nb_proc
FIN TANT QUE

Code Processus fils :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
verrouiller(nb_taches, lecture | écriture)
TANT QUE nb_taches > 0 FAIRE
    --nb_taches
    déverrouiller(nb_taches)
 
    /* Exécution de la tâche */
 
    verrouiller(nb_taches, lecture | écriture)
FIN TANT QUE
déverrouiller(nb_taches)

**Steph_ng8** · 25/10/2011, 14h34

Ce topic parle de ressources partagées entre plusieurs processus.
Mémoire commune entre deux processus - shmat

**Postgres.0** · 27/10/2011, 14h17

Merci de votre réponse,

avec la méthode où je recrée des process fils, je suis à pratiquement 100% CPU.
Donc, je vais probablement aller vers la méthode que vous avez décrite plus haut.

Seulement voilà, j'ai besoin de plus de précision sur ce code (verouiller, deverouiller...)

Merci

**Postgres.0** · 27/10/2011, 14h24

Au fait, le process père lance une requete qui va lui ramener n valeurs.
Il stocke ces valeurs dans un tableau Tab_process.
Puis il lance p fils avec les p premieres valeurs du tableau, chauqe fils execute une fonction Fonc dans laquel il y a un paramètre qui est égal à Tab_process[i], 0< i < n.

Donc quelle va etre ma resource partagée, et comment je vais améliorer le code que vous m'avez fournit précédemment pour ne plus avoir besoin de recréer des fils.

**Steph_ng8** · 29/10/2011, 19h37

Cette dernière précision change un peu la donne, en effet.
Mais du coup, on peut peut-être avoir une approche légèrement différente.

Si j'ai bien compris, le processus père connaît le nombre de tâches à effectuer, les valeurs des paramètres, et le nombre de processus fils à lancer.
Dans ce cas, il peut dès le départ donner à chaque processus la responsabilité d'effectuer p / n tâches, avec les bonnes valeurs.
Chaque processus fils obtient la liste des valeurs pour lesquelles il doit effectuer une tâche.
Et alors, plus besoin de ressource partagée.

Par exemple, il faut effectuer 12 tâches, avec les valeurs 1 à 12, et on dispose de 5 processus fils.
Le processus père peut indiquer :

fils 1 valeurs 1, 2, 3
fils 2 valeurs 4, 5, 6
fils 3 valeurs 7, 8
fils 4 valeurs 9, 10
fils 5 valeurs 11, 12

ou :

fils 1 valeurs 1, 6, 11
fils 2 valeurs 2, 7, 12
fils 3 valeurs 3, 8
fils 4 valeurs 4, 9
fils 5 valeurs 5, 10

ou toute autre combinaison satisfaisante.
Dis-moi si je suis suffisamment clair.

Sinon, pour en revenir à l'histoire des ressources partagées, je crois qu'il va falloir que tu te documentes dessus.
Comme je l'ai dit plus haut, j'en ai rarement utilisé, et je connais juste le principe pour s'en servir.

Le plus important, à mon avis, c'est que toute ressource partagée entre plusieurs processus (ou plusieurs threads) doit être associée à un verrou.
Ce verrou sert à éviter les problèmes liés à un accès concurrent (typiquement, un processus qui tente de lire la valeur d'une ressource pendant qu'un autre tente de la modifier, ou encore deux processus qui tentent de modifier simultanément la valeur d'une ressource).
Il en existe sous différentes formes, mais on les appelle communément mutex (verrou d'exclusion mutuelle).

Lorsqu'on veut accéder à une ressource, on verrouille le mutex associé, ce qui bloque l'accès aux autres processus/threads.
Une fois que l'on a fini, on déverrouille le mutex, et alors tout le monde peut de nouveau accéder à la ressource.

Il existe deux modes de verrouillage principaux :

le verrouillage en écriture, qui interdit l'accès en écriture pour tous les processus/threads sauf celui qui à verrouillé le mutex ; l'accès en lecture est toutefois autorisé pour tout le monde ;
le verrouillage en lecture (en fait, en lecture et en écriture), qui interdit purement et simplement l'accès, que ce soit en lecture ou en écriture, à tous les processus/threads sauf celui qui a verrouillé le mutex.

Donc dans mon algorithme, la ligne : verrouiller(nb_taches, lecture | écriture) signifie : « poser un verrou en lecture et en écriture sur la ressource nb_taches », et la ligne déverrouiller(nb_taches) signifie : « lever le verrou sur la ressource nb_taches ».
Je n'ai malheureusement utilisé que des mutex entre threads, donc probablement gérés par un seul processus, alors je ne peux pas t'aider pour la mise en œuvre.

Concernant ton problème, je dirais que la ressource partagée pourrait être un pointeur sur la prochaine valeur à traiter du tableau des valeurs (Tab_process).
Lorsqu'il n'y a plus de valeur à traiter, tu peux soit le faire pointer sur une valeur particulière, soit mettre le pointeur à NULL ; tout dépend ce qui est le plus simple.
Tu peux aussi associer deux valeurs au mutex : le nombre de tâches restantes, et la prochaine valeur à traiter.

Bon courage !

**ManusDei** · 05/12/2011, 14h03

Petit remontage de topic.

Dans la solution proposée ici, si je supprime le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (children < MAX_CHILDREN)

et le else associé, je fais sauter la limite du nombre de fils maximum existant en même temps, non ?

Donc le programme me créera mes N fils, en même temps ?

Multiple fork() en C

C

Discussions similaires

Partager

Partager