Discussion :

[Onimaru]

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 Delphi :

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

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

[ShaiLeTroll]

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 :

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

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

[Onimaru]

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 Delphi :

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

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 Delphi :

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

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.

[ShaiLeTroll]

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 :

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

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

Code :

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

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 :

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

1
2
3
4
5
6
destructor TOnimaru.Destroy;
begin
 FShinichi.NotifyThreadDestroy(this);
 
 inherited Destroy();
end;

Code :

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

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

[Onimaru]

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) ?

[ShaiLeTroll]

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



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 !