Discussion :

[thebop]

Voil� j'ai cod� une classe compos�e d'un socket en attribut.

Je dois cr�er un thread dans le main qui re�oit en parall�le des informations sur le socket.
Le probl�me est que pour cr�er ce thread je dois passer ma m�thode rcv() en static void... Mais qui dit static dit perte des attributs de l'instance de classe !

J'ai donc une question : Quelle est la meilleure strat�gie � employer pour pouvoir utiliser mes attributs au sein de ma classe et �tre s�r qu'ils seront bien modifi�s en parall�le dans l'objet instanc� dans mon main ?

Passer mon objet en r�f�rence ? Ce dont j'ai peur c'est que ce thread modifie un tableau dynamique attribut de mon objet... Est-ce que pour autant si je regarde l'�tat du tableau dans le main il aura bien �t� modifi� en temps r�el par le thread ?

Exemple en pseudo code pour pas piquer les yeux :

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
 
class objet{
private :
std::vector bidon
 
public:
void setvector(int);
std::vector getvector();
static void rcv(objet) //Thread qui reçoit constamment des informations en parallèle
}
 
int main()
{
   objet obj;
   obj.setvector(5);
 
   thread(obj.rcv(&obj)); //Modifie le vector au bout de 1 seconde en ajoutant 3
 
   sleep(2);
   obj.setvecor(8);
 
   cout << obj; //5 3 8 ?
 
return 1;
}

Merci beaucoup !

[3DArchi]

Bonjour,

Le probl�me est que pour cr�er ce thread je dois passer ma m�thode rcv() en static void... Mais qui dit static dit perte des attributs de l'instance de classe !

J'ai donc une question : Quelle est la meilleure strat�gie � employer pour pouvoir utiliser mes attributs au sein de ma classe et �tre s�r qu'ils seront bien modifi�s en parall�le dans l'objet instanc� dans mon main ?

La meilleur, je ne sais pas. Une solution souvent mise en oeuvre consiste � passer un pointeur sur l'objet en tant que param�tre de ta m�thode statique. Cette derni�re se contente ensuite d'appeler une m�thode non statique sur l'objet passer en param�tre:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
void A:static_callback(void *pv_param)
{
   return reinterpret_cast<A*>(pv)->Methode();
}

Ce dont j'ai peur c'est que ce thread modifie un tableau dynamique attribut de mon objet... Est-ce que pour autant si je regarde l'�tat du tableau dans le main il aura bien �t� modifi� en temps r�el par le thread ?

Je ne comprends pas trop quelle question tu te poses exactement.
Si tu partages un objet entre plusieurs thread, alors tu dois mettre en oeuvre un m�canisme de contr�le d'acc�s (mutex) pour fiabiliser ce partage.

[thebop]

Ok oui j'ai une question � ce propos sur les mutex... Est-ce que les mutex n'ont une utilit� qu'entre thread ? Parce que je ne vois pas tr�s bien l'utilit� de mettre des mutex dans le main avec le principe de m�moire partag�e.

[3DArchi]

Bonsoir,
Les mutex permettend un acc�s mutuellement exclusif aux diff�rentes ressources que peuvent partager des threads : le thread principal et les threads secondaires. Ca �vite par exemple, d'essayer de modifier une m�me variable en m�me temps, sans quoi le r�sultat est ind�termin�... Le probl�me de la m�moire partag�e est identique : il te faut savoir quand tu peux lire ou �crire dans la m�moire partag�e de fa�on � ce qu'aucun n'autre thread ne le fasse en m�me temps.
Sous windows, les mutex peuvent �tre nomm�s et permettrent la synchronisation d'acc�s � des ressources partag�es entre des processus.

[thebop]

Ok Ok je vais y r�fl�chir, pas simple cette affaire pour un premier projet...

Merci beaucoup

[thebop]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
void A:static_callback(void *pv_param)
{
   return reinterpret_cast<A*>(pv)->Methode();
}

Hum par contre je ne comprends pas trop en fait le fonctionnement de reinterpret_cast surtout ce que je ne comprends pas c'est qu'on renvoit une m�thode... Je pensais qu'� l'origine static_callback permettait de r�interpr�ter en tout d�but du thread mon void* en un pointeur sur mon objet mais l� j'ai du mal � saisir comment elle doit �tre appel�e et que veut dire (pv)-> Methode...

Il ne vaut mieux pas faire tout simplement :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

a = reinterpret_cast<A*>(a); // ?

Parce que dans mon thread l� je fais directement un reinterpret_cast mais le compilateur ne veut toujours pas comprendre quand je fais appel � des m�thodes de l'objet.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
void* Mobile::sendu(void* mob)
{
    mob = reinterpret_cast<Mobile*>(mob);
    string buffer;

[thebop]

La seule fa�on que j'arrive pour compiler c'est de cr�er un objet temporaire en d�but de thread :

Mobile* mobt = reinterpret_cast<Mobile*>(mob);

Mais du coup les threads ne vont pas partager le m�me objet !! (enfin je crois...)

[3DArchi]

La seule fa�on que j'arrive pour compiler c'est de cr�er un objet temporaire en d�but de thread :

Mobile* mobt = reinterpret_cast<Mobile*>(mob);

ceci ne cr�e pas un objet temporaire mais r�cup�re l'adresse dans mobt. L'objet point� est le m�me que celui fourni en param�tre � l'appel.

Mais du coup les threads ne vont pas partager le m�me objet !! (enfin je crois...)

Les adresses �tant les m�mes, ce sont les m�mes objets.

[thebop]

Ok j'avais test�, �a semble marcher.

J'ai une derni�re question, j'ai un thread qui envoi sur un socket et l'autre qui re�oit.... �videmment c'est le m�me socket... J'imagine que �a pose un probl�me et que je dois implanter des mutex par-ci par-l�.

Mais alors c'est emb�tant �a parce que si j'envoie je ne peux pas recevoir... et donc je perds �ventuellement un message que je pourrais avoir re�u pendant mon temps d'�mission.
Il faudrait mettre un syst�me de priorit� � receive() pour que d�s qu'il y ait un message re�u c'est lui qui ait la priorit� imm�diate sur send()... mais l� je ne vois pas du tout comment faire �a avec du mutex.

Ou alors on peut �mettre et recevoir sur le m�me socket car de toute fa�on on ne le modifie pas lors de ces deux actions, et le probl�me ne se pose donc plus.

Merci.

[3DArchi]

Ok j'avais test�, �a semble marcher.

J'ai une derni�re question, j'ai un thread qui envoi sur un socket et l'autre qui re�oit.... �videmment c'est le m�me socket... J'imagine que �a pose un probl�me et que je dois implanter des mutex par-ci par-l�.

Si les �changes concernent 2 threads de la m�me application, l'�change par socket ne me semble pas le plus pertinent.
Ceci dit, je ne sais pas exactement jusqu'� quel niveau tu dois s�curiser l'acc�s � ta socket dans un tel mutex. A priori, je dirais que tu dois utiliser ton mutex pour g�rer chaque appel (recv/send, mais aussi les autres). Pour les appels bloquant, je ne pense pas qu'il y ait de probl�me. En revanche, pour les appels non bloquants, j'avoue que je sais pas si en interne les acc�s sont prot�g�s contre la concurrence.