Gestion de Threads et Visual C++ 2008 Express

Bonjour !

Je suis nouveau venu à la programmation sur Windows (Vista), et j'utilise Visual C++ Express, version 2008.

Mon programme s'occupe de gérer la commande de moteurs via le port série. Actuellement, lorsque je clique sur mon bouton Go, la fonction de commande des moteurs démarre, et tout mon programme se retrouve bloqué, or j'aimerais avoir la possibilité de mettre le mouvement en pause, ou de le stopper complètement en cas de problème (ce qui revient au même d'un point de vue de programmation).

Il me faudrait donc, j'imagine, utiliser du multithreading. Lorsque je clique sur le bouton Go, un nouveau thread démarre et s'occupe du contrôle des moteurs, afin que mon UI reste utilisable pendant ce temps.

Ma question est la suivante : quelle est la bibliothèque de multithreading la plus adaptée pour Visual C++ Express ? J'ai vu qu'il y en avait une intégrée (afxwin.h) à la version normale de Visual C++, mais j'aimerais si possible ne pas avoir besoin de payer...

Merci d'avance pour vos réponses !

Rumpy

Tu n'as pas besoin de "bibliothèque" de multithreading sous Windows: L'API système et la C Run-Time Library (CRT) fournissent les fonctions nécessaires.

En l'occurrence, dans un programme C normal, tu dois utiliser la fonction _beginthreadex() (et transtyper son type de retour en HANDLE pour pouvoir appeler CloseHandle() dessus quand ce sera approprié).

PS: afxwin.h n'est pas une bibliothèque: C'est l'un des fichiers d'en-tête de la bibliothèque C++ Microsoft Foundation Classes, disponible en effet sur les versions payantes de Visual. Et cette bibliothèque est loin de se limiter au multithread: Elle contient des fonctions de collections, d'interface utilisateur (y compris un framework document/vue), de RTTI, de sérialisation...

J'ai quand même une nette préférence pour l'utilisation de CreateThread plutôt que _beginthread (ex ou pas), pour ma part... Tu as un exemple sur cette page.

Je trouve cette API nettement plus pratique que beginthread : d'une part, elle est plus proche des API correspondantes pour les processus, et d'autre part elle donne de bonnes habitudes (à savoir nettoyer tes allocations CRT avant de quitter le thread, et/ou utiliser des pointeurs intelligents).

Sauf que tu leakes tout ce que la CRT a alloué (et stocké les pointeurs en Thread-Local Storage) d'elle-même et auquel tu n'as pas d'accès manuel...

Citation:

---

Envoyé par Médinoc

Sauf que tu leakes tout ce que la CRT a alloué (et stocké les pointeurs en Thread-Local Storage) d'elle-même et auquel tu n'as pas d'accès manuel...

---

Encore faut-il utiliser les fonctions de la CRT dans ce thread... :mouarf:

Or, ce sont justement des fonctions que j'utilise très rarement en thread, où j'ai plutôt tendance à utiliser directement soit des fonctions portables provenant d'une librairie d'abstraction, soit uniquement l'API Win32 (inclus fonctions d'allocation). Le principe étant, bien entendu, de toujours utiliser les fonctions adéquates pour terminer un thread (ne pas utiliser _endthread() si on l'a créé avec CreateThread() et réciproquement).

Citation:

---

Envoyé par MSDN

If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.

---

C'est la seule restriction à l'usage de CreateThread, en fait... Le gros avantage derrière, par contre, c'est que c'est un thread "natif" et que tu parfaitement pouvoir créer ce thread en C++ / Visual, et le terminer par exemple via un programme Delphi ou C++ / GCC sans aucun risque, tout comme un TerminateThread() devient tout d'un coup nettement moins crade si jamais le thread est planté.
En contexte de DLL et/ou d'intéropérabilité, c'est un critère qui compte, mine de rien.

Si tu ne fais jamais de new et n'utilise pas la STL dans le thread en question, pourquoi pas?
Mais bon... Et aussi, il faut être sûr qu'aucune fonction d'aucune bibliothèque appelée n'utilise la CRT, sinon leak.

Merci pour vos réponses !

J'avais trouvé CreateThread(), mais lorsque je lançais mon prog, je ne pouvais pas contrôler mon UI pendant l'exécution de la fonction de contrôle des moteurs, et à la fin de cette fonction, Windows tue mon prog en disant "Pour protéger l'ordinateur, la prévention de l'exécution des données a fermé MonProg.exe.". A quoi cela est-il dû ?

Pour _beginthreadex(), je n'arrive pas à compiler. Il me dit "error C3867: &'CIC1::Form1::executeReceip'*: liste d'arguments manquante dans l'appel de fonction*; utilisez 'CIC1::Form1::executeReceip' pour créer un pointeur vers membre". Je ne comprends pas pourquoi, car mon appel de la fonction _beginthreadex() est le suivant :

Code:

---

threadHandle = (HANDLE)_beginthreadex(NULL, 0, CIC1::Form1::executeReceip, NULL, 0, &threadID);

---

avec la fonction executreReceip() définie comme ça :

Code:

---

void executeReceip(void)

---

En gros, j'aimerais que mon programme soit comme suit :

Code:

---

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

void goButtonClicked(void){ // lancement du thread de contrôle des moteurs (fonction executeReceip()) }   void executeReceip(void){ // contrôle des moteurs }   void stopButtonClicked(void){ // arrêt des moteurs et du thread }

---

Mon thread ne serait pas lancé depuis la fonction main(), est-ce que ça pourrait poser problème ?

(Désolé pour mes questions de noob et mes erreurs de termes, c'est la première fois que je fais un programme aussi "complexe" et que je touche à Windows :oops: )

executeReceip doit être une fonction ou une méthode statique et la signature
c'est

Code:

---

static void executeReceip(void *)

---

Plus précisément, avec _beginthreadex(), la signature doit être:

Code:

---

static unsigned int __stdcall executeReceip(void *);

---

Le paramètre passé doit être le pointeur vers un objet de la classe (ou une structure contenant le pointeur vers l'objet) si tu veux pouvoir invoquer des fonctions membres non-statiques dessus.

Oups, j'avais pas vu le "ex" de

Code:

---

_beginthreadex

---

.

J'ai modifié ma fonction comme vous me l'avez dit, mais j'ai maintenant les erreurs et warning suivants lors de la compilation :

warning C4441: convention d'appel de '__stdcall ' ignorée*; '__clrcall ' utilisé à la place

error C2665: '_beginthreadex'*: aucune des 2 surcharges n'a pu convertir tous les types d'arguments

peut être 'uintptr_t _beginthreadex(void *,unsigned int,unsigned int (__stdcall *)(void *),void *,unsigned int,unsigned int *)'

ou 'uintptr_t _beginthreadex(void *,unsigned int,unsigned int (__clrcall *)(void *),void *,unsigned int,unsigned int *)'

lors de la tentative de mise en correspondance de la liste des arguments '(int, int, overloaded-function, int, int, DWORD *)'

Ma fonction est :
static unsigned int __stdcall executeReceip(void*)

et mon appel :
threadHandle = (HANDLE)_beginthreadex(NULL, 0, CIC1::Form1::executeReceip, NULL, 0, &threadID);

Je dois avouer que je ne comprends pas d'où viennent ces erreurs... :(

T'es en C++/CLI ?
"executeReceip" est-elle une méthode d'une classe managée ("ref class")?

J'ai créé mon projet avec Visual C++ Express, en choisissant CLR puis Application Windows Form. Je ne sais pas si ça répond à ta première question ?

Ma fonction executeReceip est dans le même fichier que où ma fenêtre est créée (Form1.h) et donc où la fonction appelée lors du clic sur le bouton se trouve.

Est-ce que c'est assez clair ? :oops:

Si tu as un Form1.h, c'est que tu programmes pour le framework .Net.

Dans ce cas, tu n'utilises pas les bonnes fonctions de multithreading; tu dois utiliser les classes appropriées du Framework (comme System::Threading::Thread).

Dans les options du projet, j'ai :

Dans "Propriétés de configuration / Général - Prise en charge du Common Language Runtime", l'option sélectionnée est "Prise en charge pure du CLR MSIL (/clr:pure)"

Dans "Propriétés de configuration / C/C++ / Génération de code - Bibliothèque runtime", l'option sélectionnée est "DLL multithread (/MD)".

C'est donc du C++/CLI, il faut donc utiliser, de préférence pour la simplicité, les primitives .NET.
Voir la réponse de Médinoc.

Citation:

---

Envoyé par Médinoc

Si tu ne fais jamais de new et n'utilise pas la STL dans le thread en question, pourquoi pas?

---

En général, c'est le thread parent qui alloue tout, passe la structure au thread, qui recopie (bovinement) les données sur sa pile si elles sont volatiles, ou garde au contraire la référence sur les données passées par le parent.

Citation:

---

Envoyé par Médinoc

Mais bon... Et aussi, il faut être sûr qu'aucune fonction d'aucune bibliothèque appelée n'utilise la CRT, sinon leak.

---

Ce qui est toujours le cas si tu n'utilises que l'API Win32, ou des librairies basées exclusivement sur Win32.

Certes, c'est un cas spécifique, mais en général je ne crée que deux sortes de thread : soit des threads liés à l'interface / système (=> j'utilise la fonction adéquate, par exemple un CWinThread), soit ce sont des threads de communication / calcul (=> API Win32 exclusivement, avec ou sans couche de portage).


Reste effectivement que ces fonctions ne sont de toutes façons pas à utiliser dans un contexte .NET ou C++/CLI, bien entendu.

Citation:

---

Envoyé par Médinoc

Si tu as un Form1.h, c'est que tu programmes pour le framework .Net.

Dans ce cas, tu n'utilises pas les bonnes fonctions de multithreading; tu dois utiliser les classes appropriées du Framework (comme System::Threading::Thread).

---

Merci à tous ! Même si j'ai pas toujours compris tous les points de vos réponses, c'est super cool :)
Ça marche super maintenant, merci merci beaucoup ! :)
Enfin, il me reste plus qu'à implémenter mes fonctions correctement ^^

Doc + exemple de "system.threading.thread"
http://msdn.microsoft.com/fr-fr/libr...ng.thread.aspx

Yep merci, j'avais trouvé la doc et les exemples, et mon code fonctionne, c'est cool ! :)

Rebonjour !

J'aurais encore une question, à la suite de la discussion sur ce post.

J'aimerais, une fois que le thread que j'ai lancé est terminé, modifier des éléments dans ma fenêtre principale.
J'ai d'abord essayé en le faisant à la fin de ma fonction executeReceip(), mais là il me dit à l'exécution que je n'ai pas le droit de le faire.
Sinon j'ai essayé avec la fonction myThread->Join(), mais là mon thread principal est bloqué et je ne peux plus interagir avec ma fenêtre.

Y aurait-il une solution ? Merci pour vos réponses ^^

Hors de .Net, je connaissais la méthode: PostMessage().

Dans .Net, ce mécanisme est caché, donc je ne vois pas trop.
Au pire, tu peux toujours faire un timer qui regarde si le thread est terminé toutes les X secondes... (en appelant Join() avec un timeout nul).

Mais je vois aussi que d'après l'aide, Join() reste un minimum compatible avec une boucle de messages. Mais je ne sais pas exactement à quel point...

Quand il faut interagir avec des composants graphiques, il faut toujours le faire dans le thread qui a créé ces composants graphiques. Heureusement, .NET fournit des outils pour nous simplifier la vie.
http://msdn.microsoft.com/en-us/library/zyzhdc6b.aspx

Je crois que tu viens de trouver le Graal. Merci!

Merci pour ces réponses !

J'ai utilisé la méthode du Timer, c'était plus simple à implémenter je trouvais, même si c'est probablement pas la plus élégante ;-)

Ca marche nickel en tout cas, merci !

Franchement, plus simple que Invoke() ?? Ca m’étonnerait
Timer ?? Le quel, il y a toute une palanqué de timer différents.

Je te conseil très très vivement de revoir l'utilisation de la méthode Invoke, et de l'adopter.
Et plus élégante donc plus maintenable, beaucoup mais alors beaucoup plus simple que n'importe quel timer.