Communication par signaux entre thread

Recherche :

Dernière réponse
Sujet : Communication par signaux entre thread
Matheo	Putain que je suis con ! Je suis con, je suis stupide, je ne mérite même pas de vivre ! Je viens de trouver LE bug qui faisait tout chier dans mon programme et maintenant ça marche impec. C'était tellement une erreur conne que j'en ai honte ! Y'a pas à dire, des fois je me surpasse au niveau de la connerie !

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Matheo

Putain que je suis con ! Je suis con, je suis stupide, je ne mérite même pas de vivre !

Je viens de trouver LE bug qui faisait tout chier dans mon programme et maintenant ça marche impec. C'était tellement une erreur conne que j'en ai honte !

Y'a pas à dire, des fois je me surpasse au niveau de la connerie !

Matheo

Est-ce qu'il y a moyen aussi de passer des paramètres à la fonction reliée au signal ?
Ex : signal(SIGINT, Fonction_A(parametre)) ;

Matheo

Ils devraient au moins afficher un message. Sinon, à quoi elle sert la fonction pause() ?

Jar Jar

Normal, les processus fils sont morts, le programme terminé, puisque tu ne leur fais rien faire.

Matheo

Là je comprends vraiment pas ce qui se passe.

Code :

void Afficheur(int)
{
cout << "L'afficheur s'endort !" << endl;
pause();
cout << "L'afficheur se réveille!" << endl ;
} // fin de la fonction
void Fonc_Processus(int)
{
cout << "Le fils s'endort !" << endl;
pause();
cout << "Le fils se reveille !"<< endl ;
} // fin de la fonction
int main (int argc, char *argv[])
{
void Afficheur(int) ;
void Fonc_Processus(int) ;
int index ;
int i ;
int tableau_pid[3] ;
// Création des processus
for(index = 0 ; index < 2 ; index++)
{
if( (tableau_pid[index] = fork() ) == 0)
break ;
} // Fin du for
switch(index)
{
case 0 :
signal(SIGCONT, Afficheur);
break ;
case 1 :
signal(SIGCONT, Fonc_Processus);
break ;
case 2 :
cout << "Le pere s'endort !" << endl;
sleep(3) ;
cout << "Le pere se reveille !" << endl;
kill(tableau_pid[0], SIGCONT) ;
cout << "Le pere se rendort !"<<endl;
sleep(3) ;
cout << "Le pere se reveille de nouveau !" << endl;
kill(tableau_pid[1], SIGCONT);
wait(NULL) ;
wait(NULL) ;
break ;
} // Fin du switch
} // Fin du programme

J'ai essayé de simplifier le code, juste la base et ça ne marche pas !! Ça me fait comme résultat :
>toto
Le pere s'endort !
Le pere se reveille !
Le pere se rendort !
Le pere se reveille de nouveau !

C'est tout, aucun contact avec les processus fils ! Pourtant c'est pratiquement l'exemple du livre ! Je comprends vraiment plus rien !

[jfdsdjhfuetppo]--Message édité par Matheo--[/jfdsdjhfuetppo]

Jar Jar

Matheo a écrit a écrit :

Je peux pas croire qu'il ne le réveille jamais. La boucle fait que le père s'exécute à l'infini.

Tu as du mettre le père dans une autre boucle, alors... À moins que la fonction du père ne soit exécutée par erreur par un fils, sinon.

Matheo

http://pages.infinit.net/matheo/telnet.jpg
Je peux pas croire qu'il ne le réveille jamais. La boucle fait que le père s'exécute à l'infini.

Jar Jar

Tu viens de comprendre pourquoi on a inventé les sémaphores et les mutex.

Quand le père envoie SIGCONT, il est possible que le fils ne soit pas encore endormi...

Matheo

Je comprends vraiment pas !

Code :

void fonc_fils(void)
{
cout << "Le fils s'endort. Pid = " << getpid() << endl;
pause();
cout << "Le fils se reveille. Pid = " getpid() << endl;
...
}// Fin de la fonction
void fonc_papa(void)
{
cout << "Le pid du fils = " << tableau_pid[indice] << endl;
kill(tableau_pid[indice], SIGCONT);
...
}// Fin de la fonction

Ça donne ça
>Le fils s'endort. Pid = 12528
Le pid du fils = 12528

et ça tombe en boucle infini. Est-ce que je dois rajouter qqchose ?

Jar Jar

Oui, ça devrait se faire.
Enfin, je suppose que tu voulais dire switch(i)...

Au passage, évite signal et utilise plutôt sigaction (c'est plus souple et ça évite certains problèmes).

Matheo

Est-ce possible d'exécuter une fonction A lorsque j'envoie un signal SIGCONT du père au fils et une fonction B quand j'envoie un signal SIGCONT du fils au père ?
Exemple

Code :

switch
{
case 0 : // Le fils
signal(SIGCONT, Fonction_A()) ;
break ;
case NbMax : // Le pere
signal(SIGCONT, Fonction_B()) ;
break ;
} //Fin du switch

Ou même, ne pas spécifier de fonction spécifique pour le fils et traiter le signal normalement.

Jar Jar

Aucun problème pour ces deux trucs.

Matheo

Étant donné que j'ai un nombre variable de processus mais qu'ils font presque tous la même fonction, est-ce que je peux faire :

Code :

switch(i)
{
case 0 :
fonction_1();
break;
case NbMax :
//fonctions du père avec les signaux pour endormir et réveiller les processus
break;
default :
if(i < NbMax) //Juste pour s'assurer de ne pas avoir n'importe quoi
fonction_processus();
break;
} // fin du switch

Aussi, si j'envoie un signal SIGSTOP à un processus qui est en train de faire un tri, est-ce qu'il va continuer au même endroit quand je vais faire un SIGCONT ?

Jar Jar

1) fork renvoie une valeur non nulle (à savoir le pid du fils) uniquement quand on est dans le père, donc c'est le seul à rester dans la boucle, ce qui fait qu'à la fin i==NbMax.

2) Tous !

3) Du vin, du whisky, de la goutte... À peu près tout ce qui contient de l'alcool, en fait ;)

Matheo

Juste une petite précision concernant la création des processus

Code :

pid_pere=getpid();
for(i=0; i<NbMax; i++)
{
if((tableau_pid[i]=fork())==0)
break;
}
switch(i)
{
case 0:
Premiere_fonction();
break;
case 1:
Deuxième_fonction();
break;
...
case NbMax:
fonction_du_père();
}

1) Pourquoi les instructions du père se trouvent au case NbMax ?

2) À la sortie du switch, dans quel processus je me retrouve alors ?

3) Si tu bois pas de bière, tu bois quoi alors ?

Jar Jar

Matheo a écrit a écrit :

Moi je suis à Montréal ! 5000 km pour boire une bière ça fait un peu loin quand même !

Ouaip ! Surtout que je ne bois pas de bière !

Matheo

Moi je suis à Montréal ! 5000 km pour boire une bière ça fait un peu loin quand même !

Jar Jar

Matheo a écrit a écrit :

Au fait, t'habites dans quel coin ?

c01n c01n.

Euh, pardon, Lyon.

Matheo

Au fait, t'habites dans quel coin ?

Jar Jar

Matheo a écrit a écrit :

Ça y est, je commence à y voir clair dans tout ça ! C'est pas évident mais je pense que je vais parvenir à me débrouiller. Je te remercei très fort pour toutes tes indications et si t'habitais proche de chez moi, je te payerais volontiers une bière.[:z-bob]

Je t'en prie.

Matheo

Ça y est, je commence à y voir clair dans tout ça ! C'est pas évident mais je pense que je vais parvenir à me débrouiller. Je te remercei très fort pour toutes tes indications et si t'habitais proche de chez moi, je te payerais volontiers une bière.[:z-bob]

Jar Jar

Matheo a écrit a écrit :

Par contre, je ne comprends pas trop bien l'utilisation des segments de données. Je dois attacher le segment à un processus, inscrire des données dedans et les trier puis après un quantum de temps, je fais un backup et j'exécute un autre processus qui fait la même chose. Mes interrogations se situent par rapport aux segments : quel est leur utilité (à quoi ça sert?) et comment les utiliser (avec les paramètres de clé et tout le tralala) ?

Les segments de mémoire partagée, c'est un truc très compliqué pour faire des choses simples. C'est pour ça que depuis on a inventé les threads. (Pareil pour les signaux d'ailleurs, depuis on a inventé les mutex.)
Ça sert à avoir une zone de mémoire commune à plusieurs processus. Dans cette zone de mémoire, tu mets des données, par exemple sous forme d'un tableau. Tout le problème après coup est qu'il faut un moyen aux différents processus d'accéder à la même zone de mémoire : c'est la clé.

Matheo

Ouais, c'est pas pire ton affaire ! Je pense que je vais m'en inspirer :D

Par contre, je ne comprends pas trop bien l'utilisation des segments de données. Je dois attacher le segment à un processus, inscrire des données dedans et les trier puis après un quantum de temps, je fais un backup et j'exécute un autre processus qui fait la même chose. Mes interrogations se situent par rapport aux segments : quel est leur utilité (à quoi ça sert?) et comment les utiliser (avec les paramètres de clé et tout le tralala) ?

Je sens que je vais virer dingue ! [:wouaf]

[jfdsdjhfuetppo]--Message édité par Matheo--[/jfdsdjhfuetppo]

Jar Jar

Matheo a écrit a écrit :

Code :

for(i = 0 ; i < NbMax ; i++)
{
tableau_pid[i] = fork();
}

Avec ça, tu n'auras pas N processus, mais 2^N...

C'est plutôt :

Code :

pid_pere=getpid();
for(i=0; i<NbMax; i++)
{
if((tableau_pid[i]=fork())==0)
break;
}
switch(i)
{
case 0:
Premiere_fonction();
break;
case 1:
Deuxième_fonction();
break;
...
case NbMax:
fonction_du_père();
}

Matheo

Code :

for(i = 0 ; i < NbMax ; i++)
{
tableau_pid[i] = fork();
}

Bon je viens de relire les notes de cours et normalement je pense que je peux faire ça. Mais par contre, après comment je fais pour dire que je veux que mon processus X excéute la fonction que je veux ? Est-ce que ça marcherait ça :

Code :

if(tableau_pid[X] == 0)
{
Ma_fonction();
} // Fin du if

Jar Jar

1) Je vais avoir un nombre de processus variables (entre 2 et 20)à chaque exécution. Comment je fais pour en créer autant que je veux tout en enregistrant leur pid à chaque fois car il faut que je puisse les appeler par la suite ?

Bah tu fais une boucle, et tu ranges les pids dans un tableau au fur et à mesure de la création des fils.

2) Segment de mémoire partagée ? J'ai de la difficulté à bien saisir ce que ça fait car j'ai rien dans mes notes de cours là-dessus. Quelqu'un a un lien intéressant là-dessus ?

Regarde du côté de shmget, mais je ne te conseille pas de t'en servir si tu peux faire autrement, parce que c'est vraiment tordu. Ça permet de partager une zone de mémoire entre plusieurs processus.

[jfdsdjhfuetppo]--Message édité par Jar Jar--[/jfdsdjhfuetppo]

Matheo

1) Je vais avoir un nombre de processus variables (entre 2 et 20)à chaque exécution. Comment je fais pour en créer autant que je veux tout en enregistrant leur pid à chaque fois car il faut que je puisse les appeler par la suite ?

2) Segment de mémoire partagée ? J'ai de la difficulté à bien saisir ce que ça fait car j'ai rien dans mes notes de cours là-dessus. Quelqu'un a un lien intéressant là-dessus ?

Merci.

Jar Jar

Matheo a écrit a écrit :

Ouais c'est vrai ! Je prendrai pas de chance et je vais essayer de faire qqchose avec les fork(). Reste à savoir comment m'amuser à gérer tous les fils en même temps. Parce que de la façon mon TP fait, j'ai au moins 6 processus fils plus le père.

Auquel cas, soit tu t'arranges pour que les fils n'aient pas à communiquer entre eux mais seulement avec le père, soit tu utilises un segment de mémoire partagée, soit tu trouves une sale combine : je me souviens avoir utilisé jadis une cascade de tubes récursive entre fils pour faire remonter les pids jusqu'au père. Ça marchait bien (je rigole rien que de repenser à cette idée).

Matheo

Ouais c'est vrai ! Je prendrai pas de chance et je vais essayer de faire qqchose avec les fork(). Reste à savoir comment m'amuser à gérer tous les fils en même temps. Parce que de la façon mon TP fait, j'ai au moins 6 processus fils plus le père.

Yeah ![:wouaf]

Jar Jar

Matheo a écrit a écrit :

Donc si je suis sous Linux, ça pourrait marcher alors mon affaire de thread ?

Ça pourrait marcher. Je ne te le conseille vraiment pas, parce que ça peut donner tout et n'importe quoi.
En particulier, rien ne te garantit que le thread que tu as lancé avec pthread_create sera effectivement le fils du premier thread, au sens des getpid...

Matheo

Jar Jar a écrit a écrit :

Seule l'implémentation linux déroge à cette règle.

Donc si je suis sous Linux, ça pourrait marcher alors mon affaire de thread ?

Jar Jar

Matheo a écrit a écrit :

Je pensais que je pouvais éviter d'utiliser des fork() mais j'ai bien peur que ce ne soit pas possible. Il ne me reste plus qu'à me taper pas mal de code pour essayer de trouver un moyen de faire ce foutu tp.
C'est assez le bordel car j'ai des notions de processus, algorithmes de tri, lecture de fichier et répertoire, utilisation de tubes nommées, segment de données et tout ça en temps partagé ! La joie quoi !

La vache ! C'est pas des TP de tapettes, qu'on vous fait faire ;)

En fait, le problème avec les threads et les signaux, c'est que la notion de signal n'a pas lieu d'être pour un thread, vu que dans la norme POSIX tous les threads sont des contextes d'exécution du même processus (avec donc le même pid).
Seule l'implémentation linux déroge à cette règle.

Matheo

Je pensais que je pouvais éviter d'utiliser des fork() mais j'ai bien peur que ce ne soit pas possible. Il ne me reste plus qu'à me taper pas mal de code pour essayer de trouver un moyen de faire ce foutu tp.
C'est assez le bordel car j'ai des notions de processus, algorithmes de tri, lecture de fichier et répertoire, utilisation de tubes nommées, segment de données et tout ça en temps partagé ! La joie quoi !

bjbebert

Matheo a écrit a écrit :

signal(SIGCONT, Fonc_SIG_thread);
...
kill(getppid(), SIGCONT);
}
Donc en gros, je voudrais savoir si c'est possible d'utiliser une fonction avec SIGCONT du père vers le thread et une autre fonction avec SIGCONT du thread vers le père ?

Tu es dans le même process. Ce n'est pas getppid (c'est bien le père :??: ) dont tu as besoin, mais le pid du process dans lequel tu te trouves.

Jar Jar

Matheo a écrit a écrit :

Je peux utiliser des processus plutot que des threads mais je dois utiliser des SIGNAUX.
Par contre, comment je peux faire pour choisir quel processus je veux exécuter au moment X. Parce que ce que je dois faire, c'est un genre d'ordonnanceur et il faut donc que j'autorise l'exécution d'un seul processus à la fois et après un quantum de temps, je le mets en attente, je passe au suivant etc...

Je vois ça, justement les fonctions de style mutex, sémaphores et conditions des threads, ça sert à ça. Dans l'implémentation LinuxThreads, tout ça est fait à base de signaux, mais c'est assez compliqué (et c'est l'implémentation la plus crade des threads POSIX).

Bref, tout ça ne répond pas à ta question. Je pense que le plus simple, c'est de faire avec des bêtes fork. Avant de faire le fork, tu mets bien le pid du père dans une variable avec getpid, comme ça tu peux faire un kill dessus plus tard (ou alors tu utilises getppid). Le fork retournant au père le pid du fils, il peut lui envoyer un signal sans problème.

[jfdsdjhfuetppo]--Message édité par Jar Jar--[/jfdsdjhfuetppo]

Matheo

Je peux utiliser des processus plutot que des threads mais je dois utiliser des SIGNAUX.
Par contre, comment je peux faire pour choisir quel processus je veux exécuter au moment X. Parce que ce que je dois faire, c'est un genre d'ordonnanceur et il faut donc que j'autorise l'exécution d'un seul processus à la fois et après un quantum de temps, je le mets en attente, je passe au suivant etc...

Jar Jar

Beuark, quelle horreur, on n'utilise pas de signaux entre threads, ce n'est pas du tout portable, et rien ne dit que ça marchera dans une version prochaine de la glibc.

Essaye plutôt de voir du côté des conditions (pthread_cond_init) ou des mutex (pthread_mutex_init).

Matheo

Bonjour

Pour un de mes tp, je dois faire communiquer des threads par des signaux. Cependant, mon tp m'oblige à utiliser le signal SIGCONT. Je m'explique.

Code :

void Fonc_SIG_thread()
{
...
}
void Fonc_SIG_main()
{
...
}
void mon_thread()
{
signal(SIGCONT, Fonc_SIG_thread);
...
kill(getppid(), SIGCONT);
}
void main(void)
{
...
signal(SIGCONT, Fonct_SIG_main);
pthread tid1 ;
...
pthread_create(&tid1, NULL, mon_thread, NULL);
kill(&tid, SIGCONT) ;
}

Donc en gros, je voudrais savoir si c'est possible d'utiliser une fonction avec SIGCONT du père vers le thread et une autre fonction avec SIGCONT du thread vers le père ?