Problème avec TThread

Salut à tous, voici mon problème :
Pour ne pas mobiliser l'interface d'un programme j'ai utilisé un objet de type "TThread" pour faire un calcul long. Tout marche bien sauf que moi je veux que, en cas d'un arrêt manuel ou automatique du traitement, le thread se libère (Dans la partie qui gère les threads et les processus du système d'exploitation) et que l'objet "TThread" se libère (par le destructeur) aussi et qu'il devienne "nil" "FreeAndNil".

D'après ce que j'ai lu, il faut insérer des tests sur "Terminated" dans "Execute" :

Code:

---

1 2	if Terminated then Exit;

---

pour pouvoir arrêter le thread en plein travail, ça marche bien.

Je me demande s'il faut mettre quelque chose à la fin de la méthode surchargée "Execute" pour indiquer que le traitement est terminé ???

D'après ce que je sais "Terminated" devient automatiquement "True" à la fin de "Execute".

Est ce que "FreeOnTerminate" libère l'objet TThread ???

Où se situe le déclenchement de "OnTerminate" ??? est ce entre la fin du traitement du thread et la destruction de l'objet ???

Bref je veux un "FreeAndNil" automatique à la fin du traitement d'un thread comment faire ???

FreeOnTerminate libère le thread, cela fonctionne très bien, évite par contre de mémoriser l'instance (sinon gérer dans un OnTerminate la mise à nil de la référence) car c'est violation d'accès assurée sinon !
Tu peux utiliser un TEvent pour gérer aussi une éventuel synchro avec d'autres thread !

OnTerminate se produit après le Execute AVANT la destruction !
C'est lancé via un Synchronize dans le Main !

Les Delphi récents fournissent Finished pour indiquer la fin du thread, tu peux le faire toi même avec un boolean en propriété du thread mis à False par défaut et mis à True à la fin du Execute !

je pense que ton code sera

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

procedure TShinichi.LancerThread(); begin Reference := TOnimaruThread.Create(True); Reference.FreeOnTerminate := True; Reference.OnTerminate := OnimaruThreadTerminate; Reference.Start(); // Resume pour les anciens Delphi end;   procedure TShinichi.OnimaruThreadTerminate(Sender: TObject); begin if Sender = Reference then Reference := nil; end;

---

TShinichi est un objet, cela peut-être une TForm
OnimaruThreadTerminate est un TNotifyEvent, méthode privée de TShinichi
Reference est un membre privé de TShinichi

Merci pour le message,
En effet c'est la situation que j'ai :

J'ai un objet de type "TShinichi" qui contient un thread de type "TOnimaru" qui fait le calcul. Ce thread est appelé "FThread".
Or "TOnimaru" contient une référence vers un objet de type "TShinichi" appélée "FShinichi" pour permettre au thread de travailler avec les méthodes et les données de l'objet "TShinichi" qui l'appelle.

Depuis que j'ai posté le message j'ai réfléchi et je suis arrivé à une solution semblable :

Code:

---

1 2 3 4 5 6 7 8 9

procedure TShinichi.LancerThread; begin FThread := TOnimaruThread.Create(True); FThread.FreeOnTerminate := True; FThread.FShinichi := Self; // L'objet appelant le thread. FThread.OnTerminate := OnimaruThreadTerminate; FThread.Start() // J'ai CodeGear Delphi XE2 :) end;

---

Sauf que dans OnimaruThreadTerminate j'ai mis seulement le code de nettoyage.

J'ai déplacé "FThread := Nil" dans "Destroy" de "TOnimaru" comme suit :

Code:

---

1 2 3 4 5 6

destructor TOnimaru.Destroy; begin FShinichi.FThread := Nil; inherited Destroy end;

---

Et ça a marché, toutefois votre solution semble meilleure.
Merci encore.

Ah, tu avais des références croisées !
FThread (équivalent de mon Reference) dans TShinichi
Mais aussi FShinichi dans TOnimaru

C'est un problème classique de durée de vie d'un objet lorsqu'il est partagé par plusieurs threads et qu'il y a inter-dépendance !

En général, je modifie le constructeur pour lui passer en paramètre les objets dont le thread a besoin, cela évite le Suspended et le Start car le thread ne démarre qu'au AfterConstruction donc après tous les constructeurs hérités !

J'évite l'accès à des membres privés ou protégés entre les objets (essaye d'utiliser strict private le plus que possible), je privilégie des accesseurs en lecture seule ou des méthodes, par exemple, encore plus depuis que je suis en C++Builder, c'est strict pas nature !

Code:

---

1 2 3 4

procedure TShinichi.LancerThread; begin FThread := TOnimaruThread.Create(this, OnimaruThreadTerminate); end;

---

Code:

---

1 2 3 4 5 6 7

constructor TOnimaru.Create(AShinichi: TShinichi; ATerminateEventHandler: TNotifyEvent); begin inherited Create(false); FreeOnTerminate := True; FShinichi := AShinichi; // L'objet appelant le thread. OnTerminate := ATerminateEventHandler; end;

---

Code:

---

1 2 3 4 5 6

destructor TOnimaru.Destroy; begin FShinichi.NotifyThreadDestroy(this);   inherited Destroy(); end;

---

Code:

---

1 2 3 4 5

procedure TShinichi.NotifyThreadDestroy(AThread: TOnimaru); begin if FThread = AThread then FThread := nil; end;

---

Ainsi si tu prévois demain de gérer plusieurs threads dans TShinichi, tu n'auras pas à modifier le code de TOnimaru car il utilise une méthode qui masque l'implémentation de TShinichi

Merci pour cet éclaircissement, je vais faire comme vous avez dit.
Toutefois pouvez vous me dire la différence entre "private" et "strict private" et par la même occasion "published" et "automated" (je touche l'orienté objet) ?

Je t'ai donné un lien dans ma réponse Classes and Objects (Delphi) - Strict Visibility Specifiers
Lit l'ensemble de la page !

le Private, seul l'objet peut accéder à ces membres !
Attention, toutes les classes étant définies dans le même fichier peut aussi accéder au membre privé ! un peu comme si toute les classes d'une même unité était considéré comme des "classes amies" (voir java\c++)
Je pense que Delphi doit être l'un des rares langages Orienté Objet à fournir cette "souplesse"

le Strict Private, seul l'objet et uniquement lui peut accéder à ces membres !
Cela correspond au Private du Java\C++

Avant, il n'y avait que "private", Delphi était assez permissif, le "strict private" force le développeur à un meilleur respect de la POO et des "Design Pattern"
Ces dernières fournissent des règles pour l'interaction entres les objets, perso, je n'en applique que très peu tout simplement parce que je ne sais pas laquelle doit être utilisé à quel moment et pour quel objectif
En Delphi, il très facile de faire une Anti-Pattern Programmation spaghetti et Action à distance
Personnellement, je crois que je suis très doué pour les lasagnes et les spaghettis avec mes Objets :mouarf:



Published, c'est plus complexe, cela implique les RTTI et tout le mécansime de sérialization des TForm en DFM ( et encore plein d'autre chose )
Cela serait l'équivalent Delphi de la Reflexion du .NET, c'est un raccourci un peu grossier, mais c'est l'idée !

Voir TObject.MethodAddress et TObject.FieldAddress
Voir TPersistent, TComponent et TStream.ReadComponent ou encore TRemotable

automated ? euh c'est pour les Objets Automation ?
Oublie, ce n'est pas très important ! il y a d'autres façon de faire ! En général, avec l'éditeur de Bibliothèque des types, cela se fait tout seul !

Merci pour ces éclaircissements.
Une toute dernière petite requête vue votre expérience dans le domaine :
-Un très bon livre sur la POO
-Un autre pour Delphi
Et la même chose pour C, C++ et Java.

Un très bon livre, disons qu'à l'époque celui de Paul Toth était une référence pour Delphi 7

Perso, j'ai acheté des bouquins comme
"Borland C++ Version 5 - G. Leblanc - - Librairie Eyrolles"
"Livre C/C++, la bible du programmeur - K. Jamsa - - Librairie Eyrolles"
que j'ai finalement jamais lu car à l'école on faisait du C, Java et j'ai bossé sur Delphi pendant 10 ans !
Je suis aussi un gros paresseux ! Potassez un bouquin c'est pas mon truc, je fais ça au feeling ! d'où les spaghettis :mouarf:

Il y a de cela plus de 10 ans, et c'est juste depuis un an que je fais du C++Builder !

Je n'ai jamais ouvert de bouquin pour apprendre, j'ai lu l'aide, ça j'ai lu et relu ! je relis encore !
La Version française est de bonne qualité, juste la recherche qui déconne, je passe par la version anglaise pour la recherche, je lis la version EN, si je comprends pas un truc, je switch en VF (c'est à dire très souvent !)

J'ai lu le code source de classes.pas, controls.pas, ... une grande inspiration !

Salut

Tu pourra trouver des cours, des livres et des tutoriaux sur le site :
http://delphi.developpez.com/cours/
http://delphi.developpez.com/livres/

Pour la POO, voila un excellent cours :
http://fbeaulieu.developpez.com/guide/

@Shai : Intéressant ton lien Antipattern, je me sens moins seul :mouarf:

Merci pour les liens et les remarques ;)