Discussion :

[deck_bsd]

Bonjour à tous,

Voila mon problème, je voudrai pouvoir passer en paramètre à mon thread 3 variables , une de type char * et les deux autres unsigned int. Seulement voila, je ne comprend pas bien comme il faut que je fasse car dans la signature du thread le paramètre est LPVOID lParam. Donc pour passer 1 paramètre cava , suffit de faire un cast, mais pour passer plusieurs paramètres en mm temps, comment faut-il faire ?

Quelqu'un peux me donner un exemple svp ?

MErci d'avance.

[buzzkaido]

Euh, je suis pas tout à fait sûr de ce que je vais dire...

A priori, je procederais comme ça :

Definir une structure :

struct mesParametres
{
char param1;
char param2;
void *ceQueTuVeux;
balbla....
}

Ensuite, tu cree une structure, tu la remplit :

mesParametres paramPourLeThread;

paramPourLeThread.param1 = 'a';
paramPourLeThread.param2 = 'b';
paramPourLeThread.ceQueTuVeux = NULL;
blabla...

Et tu files en parametre pour le thread &paramPourLeThread (pointeur sur la structure que tu viens d'instancier)

Ensuite, dans le thread, tu fais :

mesParametres *parametres;
parametres = (mesParametres *) lParam;

et magique, tu as :

param1 = parametres->param1;
param2 = parametres->param2;
blabla...

A peu de choses pres, tu doit pouvoir t'en sortir comme ça.

[deck_bsd]

Salut,


Oui j'y avait penser, cela devrai fonctionner, cependant je suis kazi certain que une autre solution exist, il me semble avoir déjà vu cela quelque part mais plus moyen de retrouver où :s . Mais merci quand mm de ta réponse

[buzzkaido]

Une autre solution ?

Je vois vraiment pas, à part dialoguer avec le thread pour lui filer les parametres apres sa creation, mais ce n'est plus la meme chose.

A mon avis cette methode est la plus simple et la plus standard (cette procedure est courante dans l'API windows : on file en parametre un pointeur sur un objet du bon type)

Le seul inconvenient, c'est qu'il faut etre sur que la structure n'est pas detruite quand tu vas lire le pointeur.

Autrement dit, il faut des la premiere lecture recopier le contenu de la structure pointée par le parametre dans une autre aui est stockée avec le thread, sinon tu feras des lecture sur un ^pointeur qui ne pointe sur plus rien, d'ou erreur !

[hegros]

Il en n'existe pas d'autres pour passer un paramètre à une fonction de thread car c'est l'interface elle même qui le spécifie.

Si une autre solution, utiliser des variables globales....

[deck_bsd]

Yop,


Je vien de faire cette solution, cela fonctionne très bien, si on déclare la variable en static car , le thread travaillant comme un programme apart, dans ma fonction qui crée le thread une fois finie les varaibles déclarée dans celle ci sont libérée et donc les données dans le thread risque d'être effacé et donc cela revient à utiliser des fonction global quasi non ?

[buzzkaido]

Ben c'est pour ça que lors de la creation du thread, la premiere chose à faire est de recopier les membres de la structures dans des variables appartenant au thread.

Comme ça, à la fin de ta fonction, la structure est detruite, mais ce n'est pas grave car le thread ne s'en sert plus.

J'suis pas expert en thread, mais bon, j'vois ça comme ça...

Et puis ça evite d'encombrer la memoire avec des variables static ou global.

[Médinoc]

Je ne connais que deux "bonnes" façons (en supposant que la variable globale n'en est pas une).

1. Allouer dynamiquement une structure, la remplir et passer son adresse en paramètre au thread, qui la désallouera lui-même quand il n'en aura plus besoin (ou plus compliqué si les deux threads communiquent)
   

   Code C++ :

   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
   struct str
   {
   	int a;
   	int b;
   };
    
   HANDLE UneFonction()
   {
   	struct str *pStr = new struct str;
   	pStr->a = 42;
   	pStr->b = -1;
   	HANDLE hThread = reinterpret_cast< HANDLE >(
   	 _beginthreadex(NULL, 0, UneFonctionDansUnAutreThread, pStr, 0, NULL)
   	 );
   	return hThread;
   }
    
   UINT WINAPI UneFonctionDansUnAutreThread(LPVOID pvParam)
   {
   	struct str *pStr = static_cast< struct str *>(pvParam);
    
   	//Jouer avec pStr
   	//...
    
   	delete pStr;
   	return 0;
   }

2. Utiliser une structure directement sur la pile (en variable locale, quoi), plus un objet de synchronisation (typiquement un Event) que le thread signale dès qu'il a fini de lire la structure.
   

   Code C++ :

   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
   struct str
   {
   	int a;
   	int b;
   	HANDLE hEvent;
   };
    
   HANDLE UneFonction()
   {
   	struct str Str;
   	Str.a = 42;
   	Str.b = -1;
   	Str.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
   	HANDLE hThread = reinterpret_cast< HANDLE >(
   	 _beginthreadex(NULL, 0, UneFonctionDansUnAutreThread, &Str, 0, NULL)
   	 );
   	WaitForSingleObject(hEvent, INFINITE);
   	CloseHandle(hEvent);
   	return hThread;
   }
    
   UINT WINAPI UneFonctionDansUnAutreThread(LPVOID pvParam)
   {
   	struct str const *pcStr = static_cast< struct str const *>(pvParam);
   	struct str Str;
   	//copie
   	memcpy(&Str, pcStr, sizeof(Str));
   	pcStr = NULL;
   	//Signale que la structure d'origine peut être détruite.
   	SetEvent(Str.hEvent);
   	Str.hEvent=NULL; //Pas de CloseHandle() ici, puisque c'est le même hEvent
    
   	//Jouer avec Str
   	//...
    
   	return 0;
   }

[deck_bsd]

Merci à tous cela m'a bien aider.

[0x44-0x43-0x53-0x43]

Je ne connais que deux "bonnes" façons (en supposant que la variable globale n'en est pas une).

1. Allouer dynamiquement une structure, la remplir et passer son adresse en paramètre au thread, qui la désallouera lui-même quand il n'en aura plus besoin (ou plus compliqué si les deux threads communiquent)
   

   Code C++ :

   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
   struct str
   {
   	int a;
   	int b;
   };
    
   HANDLE UneFonction()
   {
   	struct str *pStr = new struct str;
   	pStr->a = 42;
   	pStr->b = -1;
   	HANDLE hThread = reinterpret_cast< HANDLE >(
   	 _beginthreadex(NULL, 0, UneFonctionDansUnAutreThread, pStr, 0, NULL)
   	 );
   	return hThread;
   }
    
   UINT WINAPI UneFonctionDansUnAutreThread(LPVOID pvParam)
   {
   	struct str *pStr = static_cast< struct str *>(pvParam);
    
   	//Jouer avec pStr
   	//...
    
   	delete pStr;
   	return 0;
   }

2. Utiliser une structure directement sur la pile (en variable locale, quoi), plus un objet de synchronisation (typiquement un Event) que le thread signale dès qu'il a fini de lire la structure.
   

   Code C++ :

   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
   struct str
   {
   	int a;
   	int b;
   	HANDLE hEvent;
   };
    
   HANDLE UneFonction()
   {
   	struct str Str;
   	Str.a = 42;
   	Str.b = -1;
   	Str.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
   	HANDLE hThread = reinterpret_cast< HANDLE >(
   	 _beginthreadex(NULL, 0, UneFonctionDansUnAutreThread, &Str, 0, NULL)
   	 );
   	WaitForSingleObject(hEvent, INFINITE);
   	CloseHandle(hEvent);
   	return hThread;
   }
    
   UINT WINAPI UneFonctionDansUnAutreThread(LPVOID pvParam)
   {
   	struct str const *pcStr = static_cast< struct str const *>(pvParam);
   	struct str Str;
   	//copie
   	memcpy(&Str, pcStr, sizeof(Str));
   	pcStr = NULL;
   	//Signale que la structure d'origine peut être détruite.
   	SetEvent(Str.hEvent);
   	Str.hEvent=NULL; //Pas de CloseHandle() ici, puisque c'est le même hEvent
    
   	//Jouer avec Str
   	//...
    
   	return 0;
   }

tu m'a sauvé la vie merci

[hegros]

Le vieux sujet qui remonte

Et puis ça evite d'encombrer la memoire avec des variables static ou global.

Que tu alloues des données dans la zone mémoire static/global, pile ou tas cela ne change ne rien puisque de toute façon il faudra allouer la même quantité de mémoire. Puis si le paramètre en question est une structure de quelques octets on ne peut pas vraiment parler d'encombrement de la mémoire...

On évite d'utiliser les globales surtout pour des raisons de conception mais bon s'il n'y a qu'un seul thread alors on peut écrire ceci façon quick and dirty

Code :

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

1
2
3
4
5
6
class MonParametrePourThreadUnique
{
   public static int Param1;
   public static char Param2;
  ...
}

La différence avec l'allocation sur le tas c'est qu'il y a moins de risques concernant l'allocation et la désallocation de la variable. Typiquement si dans le thread tu ne fais pas une copie locale de cette variable alors une fois l'appelant terminé toute tentative d'accès à la variable depuis l'adresse échouera (car elle n'est plus valide puisque l'adresse est stockée sur la pile et détruite une fois l'appelant terminé)

[bacelar]

Typiquement si dans le thread tu ne fais pas une copie locale de cette variable alors une fois l'appelant terminé toute tentative d'accès à la variable depuis l'adresse échouera (car elle n'est plus valide puisque l'adresse est stockée sur la pile et détruite une fois l'appelant terminé)

C'est faux. L'adresse sera toujours valide mais avec les valeurs d'autres données stoqués dans la pile, car la pile monte et descend de manière hératique.
L'utilisation de statique est très aléatoire dû aux optimisations des compilateurs.
Utilisez au moins le mot clé volatile.
Comme Médinoc, il y a 2 manières potables avec une nette préférence pour l'allocation dans le tas.

[hegros]

C'est faux. L'adresse sera toujours valide mais avec les valeurs d'autres données stoqués dans la pile, car la pile monte et descend de manière hératique.

C'est toi qui a faux. Tu ne sais pas si au moment où tu accèderas à la mémoire à cette adresse elle sera valide. Elle peut l'être comme elle peut ne pas l'être. Puis une adresse qui ne contient pas les données que l'on veut au départ ce n'est pas vraiment une adresse valide non plus.

L'utilisation de statique est très aléatoire dû aux optimisations des compilateurs.
Utilisez au moins le mot clé volatile.

? Des optimisations non standards ?

Comme Médinoc, il y a 2 manières potables avec une nette préférence pour l'allocation dans le tas.

Les variables globales (ou une classe static avec des attributs static ou volatile) c'est aussi une manière portable de faire mais conceptuellement moins accepté chez les C++iste.

[bacelar]

Code :

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

Puis une adresse qui ne contient pas les données que l'on veut au départ ce n'est pas vraiment une adresse valide non plus.

Une adresse valide ?
L'adresse est mappé en mémoire ou pas, c'est tous, et si elle a déjà contenue une variable locale, elle a déjà été mappé et donc est valide.
Même si son contenu n'a plus de sens pour le thread l'utilisant (l'adresse).

Optimisation standard, car si une variable n'est pas volatile, il est licite de la mettre dans un registre du CPU et les threads ne ce partagent pas ce genre de joyeuseté.

[hegros]

Même si son contenu n'a plus de sens pour le thread l'utilisant (l'adresse).

Si elle n'a pas de sens alors elle n'est pas valide. Après qu'il y a n'importe quoi à cette adresse cela n'en fait pas une adresse valide. Puis qui dit que la variable ne sera pas en lecture seul et que ton thread voudra faire une écriture ?

Optimisation standard, car si une variable n'est pas volatile, il est licite de la mettre dans un registre du CPU et les threads ne ce partagent pas ce genre de joyeuseté.

oui effectivement faut-il encore que l'application est plus d'un seul thread qui accède à la ressource static.

[bacelar]

Puis qui dit que la variable ne sera pas en lecture seul

Je ne connais aucun système qui met les pages mémoires affectées à la pile en lecture seule.
Tu as peut-être oublié que l'adresse était seule d'une variable locale, donc dans la pile.
Je crois que tu t’enfonces, hegros.

oui effectivement faut-il encore que l'application est plus d'un seul thread qui accède à la ressource static.

Connais-tu un compilateur capable de répondre à cette question. Moi, pas.
Et donc les compilateurs respectent les conventions du C++ en faisant cette optimisation, pas très agressive au demeurant.

[hegros]

Connais-tu un compilateur capable de répondre à cette question. Moi, pas.

Tu n'es pas très fufute parce que si c'est toi qui écris le programme tu connais le nombre de thread que tu crées donc si tu n'en crée que un seul il ne peux pas y avoir d'accès concurrent avec un autre thread sur une variable. C'est vrai qu'un compilateur c++ c'est assez stupide pour ne pas le savoir



Les C++iste on tendance à m'agacer à tout connaître la norme, les standards, et les optimisations des systèmes d'exploitations concernant les registres cpu et la gestion de la pagination voir même j'en suis sûr de la façon dont les threads sont ordonnancés

edit : oui il n'y a pas sur la pile de donnée lecture seul autant pour moi

[Médinoc]

Rien n'interdit à l'ordinateur de démapper la partie non-utilisée de la pile.

Ou de démapper la pile entière si le thread lanceur se termine avant le thread lancé.

Donc, le pointeur ne peut être garanti valide une fois la fonction terminée.