raoulli
Messages postés93Date d'inscriptionlundi 1 août 2005StatutMembreDernière intervention25 avril 2011
-
4 déc. 2007 à 02:25
raoulli
Messages postés93Date d'inscriptionlundi 1 août 2005StatutMembreDernière intervention25 avril 2011
-
9 déc. 2007 à 03:15
bonsoir a vous.
je me posai une question.
j'ai dans un prog plusieurs threads assez virulents.
ils sont tous reunient dans un seul exe, et ce prog commence a avoir des deffaillances d'affichage, car je pense trop stressé.
un trhead attend la reponse d'un autre qui attend une reponse de la fenetre principale, qui elle meme a crée une autre fenetre.
enfin un truc assez bourratif.
ma question etait la suivante, et si je mettais ces threads dans plusieurs dll, un gros thread par dll, ceci ne serrais pas mieux ?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 5 déc. 2007 à 13:25
Mais enfin, je ne vois pas ce que ça arrangerait d'appeler le même code depuis une dll au lieu d'une adresse fixe dans l'exe. Il n'y a rien de bien mystérieux dans cette question.
ciao...
BruNews, MVP VC++
Vous n’avez pas trouvé la réponse que vous recherchez ?
_dune2_
Messages postés141Date d'inscriptionmercredi 19 juillet 2006StatutMembreDernière intervention20 avril 2011 5 déc. 2007 à 18:05
Salut,
attention, je pense qu'il y a là un problème de compréhension ou d'appréhension entre "le code binaire" et "son exécution".
Le fait de dispatcher ton code dans une DLL partage effectivement ton code dans plusieurs fichiers binaires. Mais lors de son exécution, tous les bouts (exe + dlls) sont chargés en mémoire et ne font plus qu'un seul binaire prêt à être exécuté.
Et la reflexion de BruNews va dans ce sens, il-y-a en effet aucun avantage en terme d'exécution à utiliser une dll si ce n'est de le partager entre plusieur binaire.
Je passe par un exemple pour illustrer mon explication peut-être un peu confuse :
une fonction "toto()" appelé par "main()"
- binaire Executable contenant "main()" et "toto()"
lors de son chargement, "main" et "toto" son chargés en mémoire lors du chargement de l'executable.
puis exécution du code main() qui appelle toto()
- binaire executable contenant "main()" + une DLL contenant "toto()"
lors du chargement de l'executable, "main" est chargé. A ce moment là, le linker s'aperçoit qu'il lui manque la fonction "toto", il va donc la chercher dans la DLL pour la charger en mémoire à son tour.
puis exécution du code main() qui appelle toto()
On voit bien que le fait de déplacer la fonction "toto()" n'a rien changé à l'exécution.
Dans tous les cas, une fois ton programme complet chargé en RAM (que ce soit en une seule fois ou en plusieurs fois via des DLL), son fonctionnement est identique .. ça ne résoudra donc pas tes problèmes de surcharge CPU et engorgements divers ...
Pour résoudre ton problème, plusieurs pistes sont à explorer :
1) donner des priorités différentes à tes threads, de manière à rendre plus réactives celles qui doivent l'être, relégant automatiquement les autres en IDLE
2) mieux réorganiser tes threads de manière à regrouper les traitements entre eux et events entre eux (faire des threads processing qui ont besoin de CPU en prio-low et des threads interactifs qui ont besoin de peu de CPU en prio-high pour les rendre trés réactifs)
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 6 déc. 2007 à 08:49
Salut,
Si le programme manifeste des problèmes d'affichage,cela veut dire que la boucle des messages s'éxécute de manière incorrecte,c'est tout.
Il n'y a aucune combine pouvant résoudre ce problème.
Poster le code içi permettrait d'y voir plus clair.
raoulli
Messages postés93Date d'inscriptionlundi 1 août 2005StatutMembreDernière intervention25 avril 2011 6 déc. 2007 à 11:45
salut.
merci.
oui _dune2_, j'y avait pas penser, a deffinir les priorités des threads, en fonction de celui qui doit bosser le plus a un certain moment.Je vais faire ca et voir ce que ca donne, mais, ca va resoudre mon probleme je pense.Ils n'ont pas tous besoin de bosser a donf tout le temps.Et je vais virrer les SendMessages, et y mettre des PostMessages, ca serra deja mieux, avec un bool de controle.
Ok, ToutEnMasm, mais ma boucle de messages est tout a fait correcte, sauf que, les threads, prennent plus de priorités par rapport a la boucle de messages de la fenetre principale, elle recupere ce qui lui arrive, et elle ne doit plus recevoir grand chose, avec tout ce stresse, hi.
j'ai un quad-core, je teste, avec ce nouveau prog, ce cpu, ce qu'il est capable de faire, mais, etant nouveau (le cpu), je ne le connait pas assez, pour tirer partie de ces 4 coeurs !!!
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 7 déc. 2007 à 11:19
Salut,
Je cite
<hr />Ok, ToutEnMasm, mais ma boucle de messages est tout a fait correcte, sauf que, les threads, prennent plus de priorités par rapport a la boucle de messages de la fenetre principale, elle recupere ce qui lui arrive, et elle ne doit plus recevoir grand chose, avec tout ce stresse, hi.
<hr />
Affirmation gratuite (sans montrer le code ) et quelque peu ignorante du fait que l'on utilise le plus souvent les threads pour permettre à la boucle des messages de se dérouler normalement.
raoulli
Messages postés93Date d'inscriptionlundi 1 août 2005StatutMembreDernière intervention25 avril 2011 7 déc. 2007 à 16:17
salut, toutenmasm.
je te donne le code, alors, mais tu ne serra pas surpris.
c'est du connu, c'est du iczelion, je me sert de template, a chaque fois, pour ce qui est des fenetres.
ha, bon, ha, ben j'y ai jamais pensé, de faire un thread pour une boucle de message, j'en vois pas l'utilité, mais, si tu l'dis.
je peut te donner la boucle de dispatch:
*** proc
local msg:MSG
invoke CreateDialogParamA,hInstance,MINI_RES,NULL,addr ***DlgFunc,NULL
quant au traitement des differents messages: genre WM_********** par ***DlgFunc
c'est trop gros, mais il n'y a aucune latence dedans, enfin j'en ai pas vu.
car comme me l'a dit une autre personne, qui inclu des timers pour messurer, les temps a divers endroit de son prog, du genre bootvis, mais perso, et plus simple bien sur, je m'en sert aussi.
je vais utiliser, d'autres traitements, enfin, si je trouve une parade, (je vais la trouver), je la poste.
merci.
bye.
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 7 déc. 2007 à 17:31
Salut,
Comme ça j'y vois un peu plus clair.
S'il s'agit de faire fonctionner des threads dans une boite de dialogue,il faut s'attendre à de mauvaises surprises,les boites de dialogues gérant elles mêmes leur mémoire.Il n'est pas toujours facile de savoir ce qui est permis ou non.
Pour m'éviter de ramer dans ce genre de questions , je préfère l'utilisation d'une feuille,GDI ou SDI avec des controles créés par createwindowex.
Pour éviter de tout casser du premier coup,on peut utiliser une modeless dialogue avec boucle d'attente,aux possibilités très proche d'une feuille,mais dont l'écriture est légèrement différente d'une dialog box classique.
suit un exemple:
start:
invoke GetModuleHandle, NULL
mov hInstance,eax
invoke GetCommandLine
invoke WinMain, hInstance,NULL,CommandLine, SW_SHOWDEFAULT
invoke ExitProcess,eax
WinMain proc hInst:HINSTANCE,hPrevInst:HINSTANCE,CmdLine:LPSTR,CmdShow:DWORD
LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hDlg:DWORD ;ne sert que pendant la création
mov wc.cbSize,SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, OFFSET WndProc
mov wc.cbClsExtra,NULL
mov wc.cbWndExtra,DLGWINDOWEXTRA
push hInst
pop wc.hInstance
mov wc.hbrBackground,COLOR_BTNFACE+1
mov wc.lpszMenuName,OFFSET MenuName ; le menu en plus de la modale
mov wc.lpszClassName,OFFSET ClassName
invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax
invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax
invoke RegisterClassEx, addr wc
;------------------------------------------------------------
;-------------------------------------------------------------
invoke CreateDialogParam,hInstance,ADDR DlgName,NULL,addr WndProc,NULL
; ------------------------------------------------------------
;-------------------------------------------------------------
;La modeless dialog box a en plus de la modale,un menu.CreateDialogParam prend
;la place de CreateWindowEx .On retrouve DefWindowProc en fin de WndProc.
;WM_CREATE remplacé par WM_INITDIALOG .
; Ne pas oublier CLASS "DLGCLASS" dans le .rc,DLGCLASS peut être n'importe quel
;autre nom,il faut simplement quelle soit enregistré par RegisterClassEx
;la boucle d'attente comporte IsDialogMessage en plus
;ajout ,le style WS_THICKFRAME permet de redimensionner la dialog
;--------------------------------------------------------------
mov hDlg,eax
invoke GetDlgItem,hDlg,IDC_EDIT
invoke SetFocus,eax
INVOKE ShowWindow, hDlg,SW_SHOWNORMAL
INVOKE UpdateWindow, hDlg
.WHILE TRUE
INVOKE GetMessage, ADDR msg,NULL,0,0
.BREAK .IF (!eax)
invoke IsDialogMessage, hDlg, ADDR msg
.if eax==FALSE
INVOKE TranslateMessage, ADDR msg
INVOKE DispatchMessage, ADDR msg
.endif
.ENDW
mov eax,msg.wParam
ret
WinMain endp
WndProc proc hWnd:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
.if uMsg==WM_INITDIALOG
invoke SetDlgItemText,hWnd,IDC_EDIT,ADDR AppName
.ELSEIF uMsg==WM_DESTROY
invoke PostQuitMessage,NULL
.ELSEIF uMsg == WM_MOUSEMOVE
raoulli
Messages postés93Date d'inscriptionlundi 1 août 2005StatutMembreDernière intervention25 avril 2011 7 déc. 2007 à 21:47
salut.
merci.
je connais, ce genre de dialogue, des fois, je l'utilise.
mais, je ne vois pas ou est la difference, avec les threads ?
j'ai du zappé quelque chose, hi.
bye.
ToutEnMasm
Messages postés587Date d'inscriptionjeudi 28 novembre 2002StatutMembreDernière intervention13 décembre 20223 8 déc. 2007 à 15:21
Salut,
Pour avoir zappé quelque chose,je suis d'accord.
Je me cite.
<hr />
S'il s'agit de faire fonctionner des threads dans une boite de dialogue,il faut s'attendre à de mauvaises surprises,les boites de dialogues gérant elles mêmes leur mémoire.Il n'est pas toujours facile de savoir ce qui est permis ou non.
<hr />
Pour s'en convaincre,voir winhelp et quand même,aussi ma petite expérience dans ce domaine (voir mon site).
On zappe aussi le fait de savoir si le code est sans bug ? (quel debugger ?)
On zappe aussi le code source.
On zappe aussi le pourquoi du comment utiliser un thread.
On zappe aussi le fait de pouvoir se faire aidé en posant un problème clairement.Franchement,le zapping en matière de codage,ce n'est pas très efficace.
Un petit effort pour éviter le zapping me parait très nécessaire.