threads et dlls

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 ?

bonne soirée.
bye.
 

Si tu ne prévois pas de réemploi de ces DLLs dans un autre prog, ça ne servira à rien.

ciao...
BruNews, MVP VC++

Decharger mon prog, de ce stresse.
bye.

ok, la question n'a pas été comprise.
pas grave, je transfert du code dans  cette dll, verra bien.
bye.

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

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)

Voilà, je pense que ça pourra t'aider.

Gentoo... que du bonheur ...

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.

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

encore merci.
bonne jounée.
bye.

Salut,
Je cite

---

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.

---

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.

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

                .if eax != NULL
                    mov hInvisibleDlg,eax
                    ;=======================================================================
                    ;                              MESSAGES LOOP
                    ;=======================================================================
                    .WHILE TRUE         
                        invoke GetMessage, addr msg,NULL,0,0
                    .BREAK .IF (!eax)
                        invoke TranslateMessage, addr msg
                        invoke DispatchMessage, addr msg
                    .ENDW
                    mov     eax,msg.wParam
                .endif
ret
*** endp

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.