[MT] Galère avec thread et mutex pour accès variable

Salut, comme l'indique mon titre, je suis en train de faire mon entrée dans le monde des threads et je galère un peu.

j'ai une classe TOTO de la forme : (je mélange déclaration et définition pour limité la longueur du post)

Code:

---

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

class TOTO { public : void recup_mesg() // récupération des message { pthread_mutex_lock( &verrou ); ret.nb=recv(info.id,ret.buf,1500,0); // info.id est une socket tcp //surlaquelle je recois des message en xml pthread_mutex_unlock( &verrou ); } Recv get_mesg() // retourne ma variable { Recv temp; pthread_mutex_lock( &verrou ); temp = ret; pthread_mutex_unlock( &verrou ); return temp; }   private : Recv ret; pthread_mutex_t verrou; }     //AVEC : typedef struct { int nb; // Nombre d'octets recus char buf[1500]; } Recv;

---

le principe c'est que j'ai un thread qui fais une boucle pour récupérer mes messages (et elle les place temporairement dans ma varaible ret) avec recup_mesg
et un autre thread qui est censé récupéré les message l'un après l'autre avec la fonction get_mesg pour les parser.

le problème c'est que si je fais un cout de ret.buf au niveau de la fonction recup_mesg, j'obtiens bien mon text xml brut, mais si je le fais dans la fonction get_mesg, j'obtiens un truc bizarre (en l'occurrence un m$ )

je vois pas vraiment d'où ça vient, je me demande si ça ne serait pas un problème de verouillage, mais je ne pense pas.

merci de votre aide !

Salut,

Je ne pense pas que ce soit un problème de verrouillage non plus, est-ce qu'on peut voir ton code cpp (tu peux le simplifier pour juste laisser le problème)?

coyotte507

alors voilà ce que ça donne quand on "regroupe" mes différents fichiers :

Code:

---

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 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

--- definition des methodes et classes ---   class Listener { public:   Listener(); void lecture(); // lecture sur la socket Recv get_buffer(); // renvoie du buffer void set_listener(Sock L_socket); //mis en place de la socket   pthread_mutex_t verrou;   private:   Sock listener; // structure contenant la socket Recv ret;   };     void Listener::lecture() { cout << "Lancement de la lecture" << endl; while (1) { ret.nb = -1; // on reset la variable memset (ret.buf, 0, sizeof (ret.buf)); // on reset la variable pthread_mutex_lock( &verrou ); ret=recv(listener); pthread_mutex_unlock( &verrou ); cout << "sortie 1" << ret.buf << endl; } };     Recv Listener::get_buffer() { Recv temp; cout << "sortie 2" << ret.buf << endl; pthread_mutex_lock( &verrou ); temp = ret; // on stop dans un temps sinon on peut pas dévérouiller si on fait le return pthread_mutex_unlock( &verrou ); return temp; };       class Parseur { public:   Parseur(); void make_parse(); // fct qui fait le parse ! void action();   private:   Listener listen; Recv buffer;   };     void Parseur::action() { while (1) { buffer.nb = -1; memset (buffer.buf, 0, sizeof (buffer.buf)); buffer = listen.get_buffer(); // on récup le Recv de l'objet listener (en gros la variable ret) cout << "sortie 3" << buffer.buf << endl; make_parse(); } };       ------Main------   // initialisation des deux objets Listener ecouteur; Parseur decoupeur;   lance un thread qui excute la methode Listener::lecture x_Filament_Ameliore<Listener> fil_ecouteur(&ecouteur, &Listener::lecture);   lance un thread qui excute la methode Parseur::action x_Filament_Ameliore<Parseur> fil_decoupeur(&decoupeur, &Parseur::action);   // et là ça merde ! :D

---

sur la sortie 1 j'obtiens bien mes messages xml brut les un après les autres
sur les sorties 2 et 3 j'ai un : m$ qui apparait.

voilà je crois que j'ai tout dit
merci du coup de main !

Tes deux threads peuvent écrire au même emplacement mémoire au même moment.
Ça s'appelle un race condition, et c'est un comportement indéfini.

De plus, tu lis la donnée pendant qu'un autre thread peut être en train d'écrire dessus, donc c'est pas étonnant si le résultat n'est pas bon.

Citation:

---

De plus, tu lis la donnée pendant qu'un autre thread peut être en train d'écrire dessus, donc c'est pas étonnant si le résultat n'est pas bon.

---

mais le but d'utiliser des verrous c'est pas de palier à ce problème ?

Salut,

Essaye de rajouter un autre mutex qui gere l'impression.

Je me demande egalement si ce ne searait pas pertinent d'avoir des mutex separes pour la reception et la transmission

Salut alpidor,

je vois pas trop où tu veux en venir, le seul cout où j'aurais éventuellement besoin de mettre un mutex c'est celui de la sortie 2, mais même avec ça change rien

pour ce qui est des mutex séparés, je te suis pas trop. Tu penses qu'ils faudrait que j'utilises des verrous différents dans mes deux méthodes ? je vois pas l'intérêt parce que si c'est pas le même verrous, il ne va pas y avoir blocage entre les deux méthodes, si ?

Salut,

D'habitude, la communication est full-duplex et je pense qu'elle doit le rester.
Si tu mets le meme mutex pour les deux cette propriete precieuse disparaitra a mon sens.

Pour l'impression : essaye de mettre un mutex et voir quel effet aura.

A+

mais ça va quand même bloqué si les mutex sont différents ?

alors, j'ai renommé le verrou dans get_buffer, en verrou2 et j'ai rajouté un verrou3 sur la sortie 2.

j'ai enlevé les sorties 1 et 3 qui ne me servent à rien pour le moment.

et résultat la sortie 2 me donne : @à
alors qu'avant j'avais un m$
est-ce encourangeant !

pour quelle raison mets-tu des mutex sur les entrees et les sorties?
il faudrait que je vois ton design

Voila des améliorations que je ferais:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

void Listener::lecture() { cout << "Lancement de la lecture" << endl; while (1) { ret.nb = -1; // on reset la variable memset (ret.buf, 0, sizeof (ret.buf)); // on reset la variable pthread_mutex_lock( &verrou ); ret=recv(listener); cout << "sortie 1: " << ret.buf; pthread_mutex_unlock( &verrou ); } };     Recv Listener::get_buffer() { Recv temp; pthread_mutex_lock( &verrou ); cout << "sortie 2" << ret.buf << endl; temp = ret; // on stop dans un temps sinon on peut pas dévérouiller si on fait le return pthread_mutex_unlock( &verrou ); return temp; };

---

J'ai juste mis les cout entre les verrous et pas en dehors, aussi il y avait un 'buffer.buf' dans lecture(), je vois buffer nulle part dans la classe Listener, j'ai remplacé par "ret.buf".

Tu as toujours ton problème?

Malheureusement pas de changement :D

pour le buffer.buf, c'est une erreur de recopiage :D c'était bien un ret.buf qu'il fallait.

Citation:

---

Envoyé par alpidor

pour quelle raison mets-tu des mutex sur les entrees et les sorties?
il faudrait que je vois ton design

---

disons que je ne sais pas trop, je ne connais pas vraiment (du tout) le fonctionnement des mutex, donc je me base sur ce que les gars qui sont en stage avec moi me disent !
qu'entends tu pars "design" ?

bon juste pour voir s'il c'est un problème d'interférence, essaie ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

void Listener::lecture() { cout << "Lancement de la lecture" << endl; while (1) { ret.nb = -1; // on reset la variable memset (ret.buf, 0, sizeof (ret.buf)); // on reset la variable pthread_mutex_lock( &verrou ); ret=recv(listener); cout << "sortie 1: " << ret.buf; pthread_mutex_unlock( &verrou ); get_buffer(); } };

---

Sinon j'ai remarqué quelquechose: while(1). En fait, en gros, tu fais une boucle infinie, t'attends de recevoir quelquechose, et tu repars pour une boucle. Dans ces condition ton verrou est quasiment toujours là, c'est peut être ca le problème.
Ta fonction recv() est bloquante :s. Normalement, si ma théorie est juste, dans le code de la fonction lecture() ci-dessus, la fonction get_buffer() marchera :D (je parle lorsqu'elle est appelée dans cette fonction comme ci-dessus).

Si c'est le cas (je me trompe peut être), alors il faudra trouver une méthode non bloquante pour ne pas monopoliser le verrou, et faire un sleep(10) à la fin de ta boucle infinie pour ne pas monopoliser le verrou.

t'as pas faux ça marche bien.

le problème c'est que je ne peux pas faire un sleep parce que mon entité de l'autre côté de ma socket envoie des message en continue, donc si je perds attends un moment je vais avoir le buffer tcp qui va se remplir, et à ce moment là je vais me retrouver dans mon receive avec la fin d'un message et le début d'un autre.

à la rigueur je peux essayer de jouer sur quelques centièmes de secondes avec le Sleep sous windows, mais sous linux, je peux pas le faire, sleep fonctionne en seconde avec des int !

Dans ce cas faut chercher une méthode non bloquante pour pas bloquer le verrou. Et si tu veux tu peux aussi chercher une méthode pour faire une attente d'un centième de seconde.

Sinon en testant (juste pour voir), est-ce que en mettant le sleep() (même si c'est en secondes), tu as ton problème?

Edit: accept est bloquante :(

Sinon, idée?

Code:

---

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

class Listener { public:   Listener(); void lecture(); // lecture sur la socket Recv get_buffer(); // renvoie du buffer void set_listener(Sock L_socket); //mis en place de la socket   pthread_mutex_t verrou;   private:   Sock listener; // structure contenant la socket Recv ret;   };     void Listener::lecture() { cout << "Lancement de la lecture" << endl; while (1) { Recv temp;//temp, on n'utilise pas celui dans la classe pour pas bloquer le verrour temp.nb = -1; // on reset la variable memset (temp.buf, 0, sizeof (temp.buf)); // on reset la variable temp=recv(listener); pthread_mutex_lock( &verrou ); ret = temp; //copiage pthread_mutex_unlock( &verrou ); cout << "sortie 1" << temp.buf << endl; } };     Recv Listener::get_buffer() { Recv temp; pthread_mutex_lock( &verrou ); cout << "sortie 2" << ret.buf << endl; temp = ret; // on stop dans un temps sinon on peut pas dévérouiller si on fait le return pthread_mutex_unlock( &verrou ); return temp; };

---

J'ai utilisé une variable temp dans lecture() pour recevoir (comme ca on n'a pas besoin de verrour pour la fonction recv qui est bloquante).
Après on copie temp dans ret. (et le verrou est seulement là).

Ca marche? :mrgreen:

et puis avec accept ça me permettra pas de recevoir mon message

sinon, j'ai essayé le Sleep sous windows avec différentes tempo jusqu'à 1 seconde et ça marche pas :d

si receive est bloquante, le seule truc que j'ai à faire c'est de m'arranger pour que mon get_buffer dans mon autre thread ne s'éxécute pas tant que c'est bloqué. le problème comment :d

EDIT : ma réponse correspond à ton premier post de la page :d

et ben toujours pas ça !
c'est drole c'est ce que j'allais tester juste avant d evoir ta réponse :d

je suis revenu au m$ sur la sortie !

je sais pas si lors du copiage de char[], c'est pas juste l'adresse du tableau qui est copié (lequel serait désalloué à chaque boucle).

Peut être il faut faire un strcpy?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

//#include <cstring> void Listener::lecture() { cout << "Lancement de la lecture" << endl; while (1) { Recv temp;//temp, on n'utilise pas celui dans la classe pour pas bloquer le verrour temp.nb = -1; // on reset la variable memset (temp.buf, 0, sizeof (temp.buf)); // on reset la variable temp=recv(listener); pthread_mutex_lock( &verrou ); ret.nb = temp.nb; //copiage strcpy (ret.buf, temp.buf); //copiage pthread_mutex_unlock( &verrou ); cout << "sortie 1" << temp.buf << endl; } };

---

le strcpy ne change rien, par contre j'ai essayé un truc c'est dans ma structure j'ai remplacer le tableau de char par un string, mais ça change pas grand chose, au lieu d'avoir un m$ j'ai du vide :D

Juste une petite question:

L'instance de la classe Listener des deux threads, c'est bien la même? sinon faut utiliser une variable statique!

j'allais te dire oui, mais je viens de percuter que c'est peut être une connerie !
si je mets en paramètre de ma classe Parseur, une instanciation de ma classe Listener, je risque plus de faire appel au contructeur de copie !!!

je vais plutôt essayer avec l'adresse de mon instanciation :D

Code:

---

1 2 3

Listener ecouteur; Parseur decoupeur;

---

Peut être:

Code:

---

1 2 3

Parseur decoupeur; Listener &ecouteur = decoupeur.listen;

---

:aie: :aie:

En fait j'ai une fonction set_listener dans mon Parseur qui se charge de ça.

mais ça change rien, toujours vide.
là je fais encore quelques tests pour voir si j'ai pas une couille ailleurs !

T'es sur que la classe est bien partagée?

Tu pourrais genre rajouter un

Code:

---

int test

---

dans ta classe listener, et la mettre à 507:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Listener ecouteur; ecouteur.test = 0; Parser decoupeur;   Parser.set_listener(ecouteur); ecouteur.test = 507;   //on regarde si la classe est bien partagée: cout << ecouteur.test << endl; cout << decoupeur.listen.test << endl; //si les deux sont identiques, la classe est partagée!

---

qu'est ce que tu entends par partagé ?


EDIT : en tout cas ça marche, le 507 je le récup très bien dans mon objet Parseur

Qu'ils aient tous les deux la même instance:

Quand le listener de Parseur est modifié, écouteur l'est aussi.

Si les instances ne sont pas partagées, aucune chance pour que dans l'autre thread get_buffer() récupère les données de la classe du premier thread.

Il faudrait aussi voir le code des threads :)

Comment tu fais pour appeler la méthode de la classe en argument? Tu la passes bien par référence?

ok, de ce côté là, pas de problème
je fais même une modif de test dans lecture()
et je la récupère biend dans mon objet Parseur

Et tu as essayé, juste par exemple, dans la fonction lecture() ne pas faire de boucle, et de faire un get_buffer() dans le même thread?

Citation:

---

Envoyé par coyotte507

Et tu as essayé, juste par exemple, dans la fonction lecture() ne pas faire de boucle, et de faire un get_buffer() dans le même thread?

---

de ce côté là, pas de problème

Donc ca vient bien de tes deux threads.

Si tu modifies test dans un thread, il l'est dans l'autre?

avec test pas de problème, je le modifie en l'incrémentant dans ma boucle while dans lecture (en dehors du verrou)
et je le lis dans get_buffer() (hors verrou aussi)

EDIT : je pense que mon problème vient d'un problème de copie du tableau de char, parce que le int contenu dans ma structure Recv passe bien !
y a surement d'autres trucs qui ont été corrigés entre temps, notamment que je suis passé du m$ à un truc vide !
maintenant me reste à trouvé pourquoi ça ne passe pas !

après des tests et des essais dans tous les sens ça doit bien être ça !
parce que mon int passe toujours sans problème, par contre le char[1500] si je reste dans le même thread ça passe, si j'en change il disparait dans la nature

quelqu'un aurait une idée d'où cela peut il venir, parce que je suis à court là !

personne n'a une idée pour me débloquer ?

bon alors, j'ai trouvé, si ça peut aider quelqu'un un jour.
c'est juste un problème de memset qu'il faut placer à l'intérieur du verrouillage pour pas avoir d'ennuis !