Discussion :

[gnogno]

Bonjour,

J'ai développé une application dans laquelle les opération "longues" sont exécutées dans des threads. L'application peut alors réagir aux sollicitations de l'utilisateur malgré le traitement en cours.

Pour des raisons pour lesquels il n'est pas la peine de s'étendre, je me demande si j'aurais pas pu faire le contraire. Je veux dire, garder le traitement des opérations longues synchrone et faire un seul thread qui s'occupe de faire "vivre" l'IHM (à priori via un synchronize puisque la VCL n'est pas thread safe). Cette solution permettrait un codage beaucoup plus simple des traitements (si j'envisage un thread/traitement il faut faire des dizaines de classes dérivées de TThread avec toute la lourdeur des mises à jour de l'IHM, sans parler du casse-tête des cas d'erreur)

Avant de partir dans l'essai de cette solution, j'aurais aimé avoir vos avis éclairés sur la question (possible/pas possible, avantages/inconvénients, ça va pas la tête, etc....

[declencher]

Bonjour,

Il y a un point que je n'ai pas compris. D'un côté tu as 1 thread principal pour ton IHM et n traitements qui se lance dans des threads (1 thread / traitement). De l'autre côté, tu dis pouvoir faire la même chose avec 1 thread principal pour tous tes traitements, et 1 thread secondaire pour l'IHM.

Pourquoi d'un côté 1 traitement / thread et de l'autre 1 thread pour tous les traitements ?

Je pense que tu es parti sur la bonne voie, sachant que tu pourrais peut être optimiser la partie traitement.

[gnogno]

Merci de ta réponse. Quelques précisions:

Les traitements ont été threadés uniquement pour ne pas bloquer le rafraichissement de l'IHM car de toutes façon, les traitements accèdent à une DLL qui n'est pas thread-safe (i.e. il n'y a jamais deux traitements simultanés).

Donc je me dis : autant supprimer tous ces threads et ne plus en faire qu'un seul qui s'occupe uniquement du rafraichissement de l'IHM (sans pouvoir déclencher de traitement parallèle). Le problème étant que la VCL n'étant pas thread-safe ça parait bizarre de s'occuper de l'IHM dans un thread, mais pourquoi pas avec un Synchronize. Je ne sais pas si cette façon de faire tiens la route, et j'hésite à partir dans de grosses modifs d'architecture (quoique ce n'est pas si énorme, ça doit être faisable dans une journée).

[DMO]

Bonjour gnogno,

Je suis du même avis que declencher.

faire un seul thread qui s'occupe de faire "vivre" l'IHM

Ne te méprends pas sur le Synchronize, il n'a pour but que de bloquer le thread pour d'attendre que le thread principal vienne executer la méthode. le thread est ensuite débloqué.

Donc faire un thread qui appelle continuellement synchronize n'a aucun intéret.

Il faut voir ce dont tu as besoin. Tu peux peut-être te passer de multi-thread si tu ne veux pas de traitements simultanés. Si tu souhaites que l'application soit accessible uniquement pour pouvoir eventuellement cesser le traitement, quelques Application.ProcessMessages bien placés pouront largement faire l'affaire, d'autant que tu n'auras alors pas de problèmes de synchronisation ou d'accès multiples aux memes ressources. Le traitement sera simplement ralenti pour rafraichir l'IHM et traiter d'eventuels messages (comme l'appui sur un bouton STOP par exemple).

Maintenant, si tu veux vraiment travailler avec l'IHM, faire autre chose pendant que un lourd traitement de fond travaille en arrière-plan, il ne faut pas hésiter à passer en multi-thread, mais selon ta première idée, surtout pas la seconde.

Cette solution permettrait un codage beaucoup plus simple des traitements

Enfin, il est vrai qu'une véritable application multi-thread doit être développée avec rigueur car comme tu as vu ca devient vite un casse tête ! J'en ais d'ailleurs encore un peu mal à la tête :p Je crois qu'il est normal que ce ne soit pas facile.

Mais il faut utiliser sans peur la solution la plus adaptée à ton problème.

[gnogno]

Merci pour ces explications très claires.

En fait (en informatique il y a toujours un "en fait" qui met tout par terre ), dans le rafraichissement de l'IHM, il y a aussi la mise à jour d'un VirtualTreeView qui tape aussi dans la DLL (cette fois-ci en réentrant).

D'autre part, il m'est impossible d'insérer des Application.ProcessMessages dans les traitements effectués dans la DLL car c'est une DLL de calcul écrite en C++.

Je vais donc garder ce que j'ai fait et demander à faire faire des modifs au niveau de la DLL pour pouvoir gérer les cas d'erreur insolubles du fait de l'architecture multi-thread : par exemple quand on déclenche un traitement qui provoque une erreur et que selon l'erreur il faut re-saisir les paramètres du traitement ou pas, il me faudra un point d'entrée dans la DLL pour vérifier ces paramètres avant de partir dans le thread.