TThread.resume est déprécié dans Delphi-2010 ; que faut-il utiliser à la place ?

Question

Dans mon application multithread

J'utilise TThread.suspend et TThread.resume

Depuis le passage de mon application à Delphi 2010, je reçois le message de guerre suivant

[Avertissement DCC] xxx.pas(277) : W1000 Le symbole 'Resume' est obsolète.

Si Resume est déprécié, que doit-on utiliser à la place ?

EDIT 1 :

J'utilise le Curriculum vitae pour démarrer le fil de discussion - comme il est créé avec 'CreateSuspended' réglé sur True et Suspendre avant que je ne mette fin au fil.

EDIT 2 :

Voici un lien vers le manuel delphi 2010

Answer 1

Charles, si tu lis le code de la classe TThread, tu trouves la réponse.

   TThread = class  
   private type  

..
..
..   
   public  
     constructor Create(CreateSuspended: Boolean);  
     destructor Destroy; override;  
     procedure AfterConstruction; override;  
     // This function is not intended to be used for thread synchronization.  
     procedure Resume; deprecated;  
     // Use Start after creating a suspended thread.  
     procedure Start;  
     // This function is not intended to be used for thread synchronization.  
     procedure Suspend; deprecated;  
     procedure Terminate;  

Voir ce lien RAD Studio 2010 : Community pulse : Le jour d'après. (Partie 2)

Edit :

Si vous devez synchroniser des threads, vous pouvez utiliser un schéma basé sur TMutex, TEvent et des sections critiques.

Au revoir.

Answer 2

Utiliser TThread.Start au lieu de .Resume

--EDIT-- Bien entendu, Start ne peut être utilisé qu'avec Delphi 2010 (et les versions ultérieures, vraisemblablement) pour démarrer un fil de discussion qui a été créé en suspension (là où vous auriez utilisé Resume auparavant).

L'utilisation de Resume/Suspend (ou des fonctions WinAPI correspondantes) pour la synchronisation des threads n'est PAS recommandée. Voir la discussion ici (voir les commentaires de Barry Kelly).

Answer 3

Suspendre et Curriculum vitae ont été (ou étaient) potentiellement brisés dans la TThread (si vous regardez la source, vous verrez que la méthode Suspend définit directement et inconditionnellement un booléen pour indiquer l'état de suspension du thread plutôt que de dériver cet état de manière plus robuste à partir du nombre d'exécutions sur le handle du thread. Ironiquement, la méthode Curriculum vitae La méthode utilise cet indicateur plus robuste pour mise à jour l'état de suspension booléen).

C'est peut-être la raison pour laquelle ils ont été dépréciés. C'est aussi pourquoi j'ai implémenté ma propre classe pour encapsuler un thread Windows avec un mécanisme de suspension et de reprise plus robuste ainsi que la possibilité de Redémarrer un fil une fois qu'il était terminé.

Je ne sais pas pourquoi leur dépréciation est censée être liée à la synchronisation. La suspension et la reprise des threads ne sont pas nécessairement liées à la synchronisation, bien que je puisse voir comment cela pourrait l'être. Il est intéressant de noter que les méthodes équivalentes de la classe Thread du framework .NET sont également marquées comme obsolètes. Et les mêmes commentaires concernant la synchronisation apparaissent dans la documentation de l'API Windows pour la suspension/reprise des threads.

Si l'utilisation de méthodes dépréciées vous rend nerveux et que vous souhaitez toujours suspendre/reprendre vos activités, vous pouvez toujours utiliser l'API Windows pour suspendre et reprendre le thread par référence à son handle .

Answer 4

Juste au cas où tout ce que vous vouliez faire était de vous débarrasser des indices du compilateur.

(1) Pour se débarrasser de l'astuce du compilateur lorsque Démarrer un fil de discussion ...

remplacer

MyThread := TMyThread.Create(True);
MyThread.Resume;

avec

MyThread := TMyThread.Create(True);
MyThread.Start;

(2) Pour se débarrasser de l'astuce du compilateur lorsque Arrêter un fil de discussion ...

remplacer

MyThread.Suspend;
MyThread.Terminate;

avec

MyThread.Terminate;

Ce n'est pas grave du tout. Méfiez-vous de tentative d'obscurcissement .

Answer 5

Le code de contrôle du comportement du fil doit se trouver dans une procédure de fil. Utilisez les objets de synchronisation appropriés et les appels API correspondants afin de suspendre/reprendre l'exécution du thread. Le faire de l'extérieur est une pratique dangereuse. Il a donc été décidé de la déprécariser.