Multithreading 如何在Delphi中选择各种线程方式？

看来我终于要在我的Delphi2009程序中实现某种线程了。如果只有一种方法的话，我会跑掉的。但我看到了几种可能性

有谁能解释一下这两者之间的区别，以及为什么我会选择一个而不是另一个

Delphi中的TThread类

借

借

。。。还有其他的吗

---

编辑：

我刚刚在2010年3月（第10期）的《创建线程的四种方法》中读到了Gabr的一篇优秀文章。你必须订阅才能获得杂志的内容，所以根据版权，我不能在这里复制任何实质性内容

总之，Gabr描述了使用TThread、直接Windows API调用、Andy的AsyncCalls和他自己的OmniThreadLibrary之间的区别。他最后确实得出结论：

“我并不是说您必须选择经典的Delphi方式（TThread）以外的任何方式，但了解您的选项仍然很好”

Mghie的回答非常透彻，并暗示OmniThreadLibrary可能更可取。但我仍然对每个人关于我（或任何人）应该如何为应用程序选择线程方法的意见感兴趣

您可以将以下内容添加到列表中：

。4.直接调用Windows API

。5.正如拉克朗在回答中所建议的那样

---

结论:

我可能会去图书馆。我喜欢加布的作品。很多年前我用过他的剖析器GPProfile，现在我用的是他的GPStringHash，它实际上是OTL的一部分

---

我唯一关心的可能是，一旦Embarcadero将64位或Unix/Mac处理功能添加到Delphi中，就将其升级为可用于64位或Unix/Mac处理。

TThread是一个封装Windows线程的简单类。创建一个带有Execute方法的子类，该方法包含该线程应该执行的代码，创建该线程并将其设置为运行，然后代码执行

AsyncCalls和OmniThreadLibrary都是在线程之上构建更高级概念的库。它们是关于任务，需要异步执行的离散工作。您启动库，它设置一个任务池，一组特殊线程，其任务是等待，直到您为它们工作，然后向库传递一个函数指针（或方法指针或匿名方法），其中包含需要执行的代码，它在一个任务池线程中执行，并为您处理许多低级细节

---

这两个库我都没用过那么多，所以我真的不能给你两个库之间的比较。试试它们，看看它们能做什么，哪一个对你来说更好。

还有另一个鲜为人知的Delphi线程库，Misha Charrett's

它基于消息传递，而不是共享内存。相同的消息传递机制用于在同一进程或其他进程中运行的线程之间进行通信，因此它既是一个线程库，也是一个分布式进程间通信库

有一个学习曲线开始，但一旦你开始，你不必担心所有的传统线程问题，如死锁和同步，框架会照顾你的大部分

---

Misha多年来一直在开发这个框架，并且一直在积极改进框架和文档。他对支持问题总是反应非常积极。

如果你没有多线程方面的经验，你可能不应该从

TThread

开始，因为它只是本机线程之上的一层薄薄的线程。我认为它也有点粗糙的边缘；自Delphi 2推出以来，它没有太大的发展，主要是为了在Kylix时间范围内允许Linux兼容性，并纠正更明显的缺陷（例如修复损坏的MREW类，最后在最新的Delphi版本中弃用

Suspend（）

和

Resume（）

）

使用简单的线程包装器类基本上也会导致开发人员将注意力集中在一个太低的级别上。为了正确使用多个CPU核，将重点放在任务上而不是线程上更好，因为使用线程进行工作划分不能很好地适应不断变化的需求和环境-取决于并行运行的硬件和其他软件，线程的最佳数量可能会有很大差异，即使在同一系统上的不同时间。在这方面，一个只将大量工作传递给您的库，它会自动安排这些工作，以最大限度地利用可用资源

异步调用是将线程引入应用程序的良好第一步。如果您的程序中有几个区域需要执行许多相互独立的耗时步骤，那么您可以通过将每个步骤传递给异步调用来异步执行它们。即使只有一个这样耗时的操作，您也可以异步执行它，并在VCL线程中显示一个进度UI，可以选择取消该操作

异步调用对于在整个程序运行时停留的后台工作人员来说不是很好，并且当程序中的某些对象具有线程关联性时（例如数据库连接或OLE对象，它们可能要求所有调用都在同一线程中发生），异步调用可能无法使用

您还需要注意的是，这些异步操作并不是“开火然后忘记”的类型。每个重载的

AsyncCall（）

函数返回一个

iasyncall

接口指针，如果要避免阻塞，可能需要保留对该指针的引用。如果不保留引用，那么当ref计数达到零时，接口将被释放，这将导致线程释放interf