BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 11 nov. 2005 à 09:16
1L ou 1 c'est idem.
Inekman
Messages postés291Date d'inscriptiondimanche 2 février 2003StatutMembreDernière intervention30 juin 2006 11 nov. 2005 à 08:55
Je m'aide de ton code pour implémenter un arrêt d'un thread dans un de mes programmes fait en Delphi, cependant je ne parviens pas à définir la contante D_TIME_OUT_TEST à 1L, quelle est cette valeur ?
Merci.
ncoder
Messages postés244Date d'inscriptionvendredi 6 mai 2005StatutMembreDernière intervention 6 avril 20081 3 sept. 2005 à 10:54
Non la source est assez courte pour la comprendre sans avoir besoin de beaucoup de commentaires !
Merci pour ta source, elle est très bien faite (pour commencer!) ;)
NitRic
Messages postés402Date d'inscriptionmardi 1 mai 2001StatutMembreDernière intervention15 août 2011 7 sept. 2004 à 21:54
Pas besoin de boucle, WaitForSingleObject()/WaitForMultipleObjects() sont parfait pour ce type de `boulot` ...
un while(var); est `strictement` déconseillé. Peu importe le type de projet. Il y à les sections critiques, mutex, event, semaphore, ... pour la synchronisation ...
cs_AlexMAN
Messages postés1536Date d'inscriptionsamedi 21 décembre 2002StatutMembreDernière intervention24 mai 20091 19 juil. 2004 à 12:24
ben en fait, je ne comprends pas ou placer WaitForSingleObject dans la threadProc. Comment gerer plusieurs threads est vraiment un mystere ! Kan faire (pour les event) un SetEvent, ou un ResetEvent pour permettre aux autres threads de s'executer, enfin je gere pas du tt kan le nbre de threads (sans compter le thread principal) depasse 1.
cs_Arnotic
Messages postés933Date d'inscriptiondimanche 1 avril 2001StatutMembreDernière intervention 9 janvier 2012 19 juil. 2004 à 12:17
Je verra pour faire un exemple d'appli comme ca alors. Sinon qu'est-ce que tu ne comprends pas exactement ?
cs_AlexMAN
Messages postés1536Date d'inscriptionsamedi 21 décembre 2002StatutMembreDernière intervention24 mai 20091 19 juil. 2004 à 12:11
Arnotic > personnelement, j'ai enormement de pb avec les threads, jme suis tapé Petzold mais j'ai pas plus compris (serai je un cas desespéré ?!), donc jvoulais te demander ds la limite de ton temps disponible (?!), si tu pouvais pas nous faire une ptite applic Multi-Thread avec un peu plus de threads kici (avec event, mutex, section critique...)...Voila c seulement si tu as du temps, sinon c po grav, jV aller me taper Richter...merci
++
ALhexman
cs_Arnotic
Messages postés933Date d'inscriptiondimanche 1 avril 2001StatutMembreDernière intervention 9 janvier 2012 19 juil. 2004 à 08:24
En fait si le Thread ne vient pas prendre 100% du CPU c'est juste grace au Sleep(). le mieux mettre en Sleep(10L); quand très très peu de traitement dans le thread.
Après on peut justement ne pas mettre de Sleep() pour une aplication en plein ecran pendant qu'elle traite des données pour allez plus vite.
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 18 juil. 2004 à 13:50
Enfin mets D_TIME_OUT_TEST à 0 et il va aussi te bouffer toute ta cpu
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 18 juil. 2004 à 13:47
Bah oui mais quand on a un processus qui doit utiliser beaucoup de mémoire, il faut bien le faire. Essaie de calculer 100000! avec maple et tu verra que ta cpu est à 100%
cs_AlexMAN
Messages postés1536Date d'inscriptionsamedi 21 décembre 2002StatutMembreDernière intervention24 mai 20091 18 juil. 2004 à 13:43
vecchio56 > ya un sleep(100) ds ta boucle, c normal ke ca pompe pas le cpu comme un malade...enleve le, teste sur un grand nombre, et regarde l'activité de ton cpu...
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 18 juil. 2004 à 13:35
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 18 juil. 2004 à 13:35
Non j'ai fait un programme qui faisait de gros calculs, que je devais arrêter quand je voulais, eh bien la solution avec un booléen était bien meilleure (d'autant meilleure qu'on vérifie souvent s'il faut arrêter le thread - il est évident que regarder si un booleen est tru ou false va plus vite qu'appeler une fonction qui va regarder en plus des HANDLE).
Tu n'a qu'a essayer sur cet exemple, le cpu n'est pas du tout occupé, de ce coté la ca ne change structement rien.
D'ailleurs je ne voie pas pourquoi ca utiliserait plus de cpu??
cs_AlexMAN
Messages postés1536Date d'inscriptionsamedi 21 décembre 2002StatutMembreDernière intervention24 mai 20091 18 juil. 2004 à 13:28
en terme de rapidité je pense pareil ke toi, mais cela n'empeche pas ke le cpu sera ocupé a 99% par ton thread, et c vraiment un truc a eviter..
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 18 juil. 2004 à 13:22
Bah non, le while(b) sera plus rapide que le while( WaitForSingleObject( d_eventStop, D_TIME_OUT_TEST ) == WAIT_TIMEOUT ); qui va beaucoup ralentir le thread
cs_AlexMAN
Messages postés1536Date d'inscriptionsamedi 21 décembre 2002StatutMembreDernière intervention24 mai 20091 18 juil. 2004 à 13:18
Un booleen est TOTALEMENT deconseillé ds l'utilisation de thread : utilisation du CPU de minimum 99% avec cette methode...
vecchio56
Messages postés6535Date d'inscriptionlundi 16 décembre 2002StatutMembreDernière intervention22 août 201014 13 mai 2004 à 12:58
Le problème avec ton truc c'est que ce n'est pas satisfaisant pour un thread qui devrait aller vite, puisque l'appel à WaitForSingleObject prend pas mal de temps. Pourquoi ne pas utiliser un simple booléen qui dit s'il faut arrêter?
cs_Arnotic
Messages postés933Date d'inscriptiondimanche 1 avril 2001StatutMembreDernière intervention 9 janvier 2012 24 févr. 2004 à 19:57
Il me semblait que la source etait suffisamente petite pour arriver à s'y retourver.
Je prends note.
cs_LordBob
Messages postés2865Date d'inscriptionsamedi 2 novembre 2002StatutMembreDernière intervention11 mai 20099 24 févr. 2004 à 18:30
tu aurrais peut etre pu un peu plus expliquer ta source pour que les debutant, comprenne un peu mieux !!! car moi si je ne savait pas comment créer un thread, bah j'aurrais galéré pour bien comprendre ta source !!!
11 nov. 2005 à 09:16
11 nov. 2005 à 08:55
Merci.
3 sept. 2005 à 10:54
Merci pour ta source, elle est très bien faite (pour commencer!) ;)
7 sept. 2004 à 21:54
switch ( dwRet ) {
case WAIT_TIMEOUT:
...
break;
case WAIT_FAILED:
...
break;
case WAIT_OBJECT_0:
...
break;
case _WAIT_ABANDONNED:
/* mutex only */
break;
}
Pas besoin de boucle, WaitForSingleObject()/WaitForMultipleObjects() sont parfait pour ce type de `boulot` ...
un while(var); est `strictement` déconseillé. Peu importe le type de projet. Il y à les sections critiques, mutex, event, semaphore, ... pour la synchronisation ...
Petit tutorial parfait à propos du multithreadnig(pour les interessés);
http://bob.developpez.com/tutapiwin/article_46.php
~(.:: NitRic ::.)~
19 juil. 2004 à 12:24
19 juil. 2004 à 12:17
19 juil. 2004 à 12:11
++
ALhexman
19 juil. 2004 à 08:24
Après on peut justement ne pas mettre de Sleep() pour une aplication en plein ecran pendant qu'elle traite des données pour allez plus vite.
18 juil. 2004 à 13:50
18 juil. 2004 à 13:47
18 juil. 2004 à 13:43
18 juil. 2004 à 13:35
#include <windows.h>
#include
#include <stdlib.h>
#include "resource.h"
#define D_TIME_OUT_TEST 1L
HWND hstatus;
BOOL b;
DWORD Thread_TestID;
DWORD WINAPI Thread_Test( LPVOID lpParam )
{
int inc=0;
char *szbuff;
if (!(szbuff = (char *)malloc(4)))
return 1;
do
{
if (inc == 99)
b = FALSE;
SetWindowText(hstatus, itoa(++inc, szbuff, 10));
Sleep(100L);
} while(b);
free(szbuff);
MessageBox(NULL, "Arret du thread.", "Stop", 0x40);
return 0;
}
BOOL CALLBACK AppDlgProc(HWND hdlg, UINT mssg, WPARAM wParam, LPARAM lParam)
{
switch(mssg)
{
case WM_INITDIALOG:
SetClassLongPtr(hdlg, GCL_HICON, (LONG)(LONG_PTR)LoadIcon(0, IDI_APPLICATION));
hstatus = GetDlgItem(hdlg, IDC_STATUS);
return 1;
case WM_COMMAND:
switch(wParam)
{
case IDC_START:
b = TRUE;
CreateThread(NULL, 0, &Thread_Test, NULL, NULL, &Thread_TestID);
return 0;
case IDC_STOP:
b = FALSE;
return 0;
case IDCANCEL:
EndDialog(hdlg, 0);
}
}
return 0;
}
int WINAPI WinMain(HINSTANCE hinst, HINSTANCE, PSTR, int)
{
DialogBoxParam(hinst, (LPCTSTR)IDD_APP, 0, AppDlgProc, 0);
return 0;
}
18 juil. 2004 à 13:35
Tu n'a qu'a essayer sur cet exemple, le cpu n'est pas du tout occupé, de ce coté la ca ne change structement rien.
D'ailleurs je ne voie pas pourquoi ca utiliserait plus de cpu??
18 juil. 2004 à 13:28
18 juil. 2004 à 13:22
18 juil. 2004 à 13:18
13 mai 2004 à 12:58
24 févr. 2004 à 19:57
Je prends note.
24 févr. 2004 à 18:30