2010-11-17 5 views
8

dans delphi XE i peut utiliser la procédure de démarrage, mais cette méthode n'existe pas dans delphi 2007.Quelle est la bonne façon de démarrer un thread suspendu dans Delphi 2007?

cet exemple de code fonctionne bien dans delphi x €, en utilisant Démarrer

MyThread:=TMyThread.Create(True); 
MyThread.FreeOnTerminate :=True; 
MyThread.Property1:=900; 
MyThread.Property2:=2; 
MyThread.Start; 

mais delphi 2007, le start La procédure n'existe pas, donc j'utilise la procédure de reprise qui est déconseillée dans les nouvelles versions de Delphi.

MyThread:=TMyThread.Create(True); 
MyThread.FreeOnTerminate :=True; 
MyThread.Property1:=900; 
MyThread.Property2:=2; 
MyThread.Resume; 

de sorte que le quieon est, il est utilisé ok resume dans delphi 2007 ou je dois utiliser une autre façon de commencer un fil suspendu?

Merci d'avance.

Répondre

19

La bonne façon de commencer un fil suspendu est de ne jamais avoir un fil suspendu en premier lieu.

Il existe un meilleur moyen de créer des threads. Si l'appelant doit fournir une valeur à l'objet pour que la classe fonctionne correctement, ne le rendez pas facultatif: Exigez-le en tant que paramètre pour le constructeur. Et s'il n'y a qu'une seule valeur valide pour ce paramètre, alors n'en faites même pas un paramètre: il suffit de le coder en dur dans le constructeur. (? Combien de fois avez-vous écrit une classe de fil qui ne parfois devrait se libérer de la fin, je ne l'ai jamais vu ça.)

constructor TMyThread.Create(Prop1, Prop2: Integer); 
begin 
    inherited Create(False); 
    FreeOnTerminate := True; 
    Property1 := Prop1; 
    Property2 := Prop2; 
end; 

Ensuite, vous pouvez utiliser la méthode Ron Popeil de créer des fils: Juste Réglez-le et oubliez-le!

MyThread := TMyThread.Create(900, 2); 

L'appelant n'a rien à voir avec le fil après l'avoir créé. Et comme il s'agit d'un thread à terminaison libre, il est possible que l'appelant ne garde même pas une référence à la variable MyThread car la référence deviendra invalide dès que le thread sera exécuté.

(Inquiet à propos de cette ligne inherited Create(False) créant un thread qui va commencer à s'exécuter avant que le reste du constructeur ne termine son exécution? Ne soyez pas! Cela a été corrigé dans Delphi 6, il y a plus de dix ans. après la fin du constructeur, voir TThread.AfterConstruction pour voir comment.

+1

+ Inf pour le dernier paragraphe – arthurprs

+0

Merci pour les informations supplémentaires sur l'ordre de création et d'exécution. J'ai toujours commencé à suspendre les discussions et je les ai repris avec cette peur exacte. –

1

Oui, c'est le bon moyen pour les anciennes versions de Delphi qui n'ont pas de procédure Start.

1

Résumé et suspension sont obsolètes dans Delphi 2010 et versions plus récentes. Il semble que c'est essentiellement pour décourager leur utilisation pour la synchronisation des threads. Ils ne sont pas faits pour ça.

De toute façon, si tout ce que vous voulez faire est de reprendre un thread créé suspendu, puis l'appel Resume dans les versions plus anciennes est sûr.

Si vous devez utiliser le même code source dans Delphi 2007 et Delphi XE, vous pouvez utiliser la compilation conditionnelle pour éviter les avertissements dans XE.

Aussi, jetez un oeil à cette question qui est liée à votre question:

TThread.resume is deprecated in Delphi-2010 what should be used in place?

0

Vous ne devez jamais appeler suspendre sur un tthread, ce n'est pas sûr et reprendre ne doit être utilisé que pour démarrer un thread qui a été créé suspendu.

Dans Delphi 2010, la suspension et la reprise, lorsqu'elles ont été dépréciées, et le début de la méthode a été introduit pour renforcer cela.

Pour une explication plus complète, voir ce thread sur les forums Codegears.

5

Il n'y a rien de mal à appeler Resume sur un thread qui a été créé avec le jeu de paramètres CreateSuspended à true dans le constructeur. (Pourquoi sinon y aurait-il un paramètre CreateSuspended après tout?)

Cependant, le vrai problème survient lorsque vous suspendez/reprenez un thread en cours d'exécution. Cela est principalement dû aux références aux ressources ouvertes, telles que les objets COM. (Par exemple, si un objet de connexion ADO est actif et qu'une requête est en cours d'exécution ... il n'est pas idéal de suspendre ce thread et d'essayer de le reprendre plus tard ... il est évident que ça ne fonctionnera pas toujours bien pour vous ou Si vous faites attention avec vos références externes, suspendre/reprendre un thread en cours d'exécution devient beaucoup plus sûr, sauf pour les conditions de course possibles qui peuvent surgir ... mais ce sont des réponses pour beaucoup d'autres questions ...

+0

Ou en général, toute instance lorsque vous envoyez une sorte de demande et attendez une sorte de réponse. –

Questions connexes