Discussion :

[Rumpy]

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

[M�dinoc]

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...

[Mac LAK]

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).

[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...

[Mac LAK]

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...

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).

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.

[M�dinoc]

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.

[Rumpy]

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 :

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

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

avec la fonction executreReceip() d�finie comme �a :

Code :

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

void executeReceip(void)

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

Code :

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

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 )

[bacelar]

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

Code :

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

static void executeReceip(void *)