Discussion :

[benj63]

Bonjour,

J'utilise actuellement des threads pour lancer des calculs simultanément à travers une application. Ces calculs correspondent à l'ouverture de fichiers, au lancement de programmes externes, à la récupération des résultats, puis au tracé d'images à partir de ces résultats.

Au milieu de mes threads, il m'arrive d'utiliser des appels à des objets de la VCL. Or j'ai lu qu'il ne fallait pas les utiliser sans passer par un Synchronize(). Le problème, c'est que cela entraîne plein de fonctions supplémentaires à créer dans le Thread, sans passage des paramètres dans les arguments de la fonction puisque Synchronize() s'utilise ainsi :
Synchronise(Affichage);
Affichage étant une fonction "void Affichage();"

Bref !! Je fais dans mes threads beaucoup de références à d'autres fonctions sans passer par des synchronize (par manque de temps, et pour ne pas trop alourdir le code avec 50000 fonctions supplémentaires au sein du thread) : ouverture de fichiers, tracé sur le Canvas d'images, etc...

Il arrive (malheureusement pour moi) que le thread plante : par exemple, la fonction Execute de mon thread contient le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
bmp = new TBitmap1(mon_fichier);   // TBitmap1 est un objet que j'ai développé, dérivé de TBitmap
bmp->Canvas->Pixels[x0][y0] = TColor(RGB(255,0,0)); // par exemple

il arrive que le thread plante sur bmp->Canvas->Pixels en m'affichant l'erreur suivante : "objet inaccessible". Je me demande un peu pourquoi le thread plante là, puisque je ne trace pas sur le Canvas de la Form (dans ce cas là, je comprendrais car d'autres threads doivent sûrement y accéder), mais sur le Canvas d'un Bitmap que je n'ouvre qu'à partir de ce thread (et qui n'est pas ouvert en même temps par un autre thread).

J'imagine que je devrais passer par un Synchronize, mais est-ce qu'un try {bmp->Canvas->Pixels...} catch(...) {} pourrait corriger cela ? Ou y'a-t'il un moyen de mettre en oeuvre une méthode similaire à Synchronize (mais simplifiée, sans la création d'une autre fonction par exemple !!) qui éviterait ces plantages ?

Pouvez-vous également m'indiquer quels sont les fonctions critiques qu'il faut éviter d'appeler directement dans les threads (tels que Form->Label->Caption = ...") ?

Merci par avance pour vos idées et vos réponses !!

Cordialement...

[BrunoMolto]

Bonsoir,

J'ai aussi été confronté à ce pb.
Je ne pense pas qu'il y ait de contournement à cette méthode, car la VCL n'est pas "thread safe".
Le plantage sévère est encore la meilleure des sanctions. En effet, il existe des pièges encore pire :
Constatant qu'une application plantait aléatoirement après quelques heures de foncionnement, après maintes recherches (plusieurs jours), j'ai pu mettre en évidence que le plantage était dû à des fuites mémoires (consommation de ressources insidieuses) simplement en passant des AnsiString en argument de fcts thread! Seul memproof m'a permis de localiser le pb.

La seule solution réellement efficace fut de réécrire les interfaces en utilisant des chaines C standard.
Donc depuis, point de salut sans Synchronize ! !

Bon courage!

[benj63]

Merci à toi BrunoMolto...

Je fais un ptit UP, au cas où !

Quelqu'un d'autre a-t'il déjà été confronté à ce même type de problème, et a-t'il su les résoudre ?

[mat.M]

Pas trop le temps d'étudier le problème mais ce que je peux dire c'est que si tu ne peux le résoudre alors shunter la VCL graphique et appeler directement les API et API graphiques avec HDC