Si vous n'avez pas d'expérience en matière de multithreading, vous ne devriez probablement pas commencer par l'option TThread car il ne s'agit que d'une fine couche sur le filage naturel. Je le considère également comme un peu brut de décoffrage ; il n'a pas beaucoup évolué depuis son introduction avec Delphi 2, principalement des changements pour permettre la compatibilité avec Linux à l'époque de Kylix, et pour corriger les défauts les plus évidents (comme la correction de la classe MREW cassée, et enfin la dépréciation de la classe MREW). Suspend() y Resume() dans la dernière version de Delphi).
L'utilisation d'une simple classe d'enveloppes de fils fait également en sorte que le développeur se concentre sur un niveau beaucoup trop bas. Pour faire bon usage de plusieurs cœurs de processeur, il vaut mieux se concentrer sur les tâches plutôt que sur les threads, car le partitionnement du travail avec des threads ne s'adapte pas bien aux exigences et aux environnements changeants - selon le matériel et les autres logiciels fonctionnant en parallèle, le nombre optimal de threads peut varier considérablement, même à différents moments sur le même système. Une bibliothèque à laquelle vous ne passez que des morceaux de travail et qui les planifie automatiquement pour utiliser au mieux les ressources disponibles est très utile à cet égard.
AsyncCalls est une bonne première étape pour introduire les threads dans une application. Si vous avez plusieurs zones dans votre programme où un certain nombre d'étapes chronophages doivent être exécutées, indépendamment les unes des autres, vous pouvez simplement les exécuter de manière asynchrone en passant chacune d'entre elles à AsyncCalls. Même lorsque vous n'avez qu'une seule action qui prend du temps, vous pouvez l'exécuter de manière asynchrone et simplement afficher une interface utilisateur de progression dans le thread VCL, permettant éventuellement d'annuler l'action.
AsyncCalls n'est pas très bon pour les travailleurs d'arrière-plan qui restent en place pendant toute la durée d'exécution du programme, et il peut être impossible de l'utiliser lorsque certains des objets de votre programme ont une affinité avec les threads (comme les connexions de base de données ou les objets OLE qui peuvent avoir une exigence que tous les appels se produisent dans le même thread).
Ce dont vous devez également être conscient, c'est que ces actions asynchrones sont no du genre "tirer et oublier". Toute surcharge AsyncCall() renvoie un IAsyncCall pointeur d'interface auquel vous devrez peut-être conserver une référence si vous voulez éviter le blocage. Si vous ne conservez pas de référence, l'interface sera libérée dès que le nombre de références atteindra zéro, ce qui obligera le thread qui libère l'interface à attendre que l'appel asynchrone soit terminé. C'est quelque chose que vous pouvez voir pendant le débogage, lorsque vous sortez de la méthode qui a créé l'interface. IAsyncCall peut prendre un temps mystérieux.
OTL est à mon avis la plus polyvalente de vos trois options, et je l'utiliserais sans hésiter. Il peut tout faire TThread et AsyncCalls peuvent faire, et bien plus encore. Il a une conception saine, qui est suffisamment de haut niveau pour rendre la vie de l'utilisateur facile, et pour laisser un portage vers un système Unixy (tout en gardant la plupart de l'interface intacte) sembler au moins possible, sinon facile. Au cours des derniers mois, il a également commencé à acquérir quelques constructions de haut niveau pour le travail en parallèle, ce qui est fortement recommandé.
OTL dispose également de quelques dizaines d'échantillons, ce qui est important pour commencer. AsyncCalls n'a rien d'autre que quelques lignes de commentaires, mais il est assez facile à comprendre en raison de sa fonctionnalité limitée (il ne fait qu'une chose, mais il la fait bien). TThread n'a qu'un seul échantillon, qui n'a pas vraiment changé en 14 ans et qui est surtout un exemple de ce qu'il ne faut pas faire.
Quelle que soit l'option choisie, aucune bibliothèque n'éliminera la nécessité de comprendre les bases de l'enfilage. La lecture d'un bon livre à ce sujet est une condition préalable à tout codage réussi. Le verrouillage correct, par exemple, est une exigence de toutes les bibliothèques.
