本章内容：

  • 对线程的解释

  • TThread对象

  • 管理多线程

  • 一个多线程的示范程序

  • 多线程与数据库

  • 多线程与图形处理

 

  Wi n 3 2操作系统提供了在应用程序中执行多线程的能力。从1 6位的Wi n d o w s升级到Wi n 3 2的一个最大受益便是：它允许多线程同时运行。这也是要升级到 3 2位D e l p h i的一个最主要的原因。本章提供了程序中如何进行多线程编程的所有细节。

 

11.1   对线程的解释

  如同在第3章“Win32 API”中所讨论过的，线程是一种操作系统对象，它表示在进程中代码的一条执行路径。在每一个Wi n 3 2的应用程序中都至少有一个线程，它通常被称为主线程或默认线程。在应用程序中也可以自由地创建别的线程去执行其他任务。线程技术使不同的代码可以同时运行。当然，只有在多 C P U的计算机上，多个线程才能够真正地同时运行。然而，由于操作系统把C P U的时间分成很短的片段分配给每个线程，这样给人的感觉好像是多个线程真的同时运行。提示 线程不能也从来没有被16位的Windows支持。这就意味着， 任何32 位版本 的Delphi的多线程程序代码都有无法在Delphi 1环境下编译。如果你在为这两个平台开发程序，请一定记住这一点。

 

11.1.1   一种新型的多任务

  线程的概念与1 6位环境中的多任务有很大的不同。或许曾听人们这样讲： Wi n 3 2是一种抢占式操作系统，而Windows 3.1是一种协作式的多任务环境。其关键区别在于：在抢占式多任务环境中，操作系统负责管理哪个线程在什么时候执行。如果当线程1暂停执行时，线程2才有机会获得C P U时间，我们说线程1是抢占的。如果某个线程的代码陷入死循环，这并不可怕，操作系统仍会安排时间给其他线程。在Windows 3.1下，程序员必须保证应用程序能够把控制权返还给Wi n d o w s。如果这一步失败，将导致整个操作环境锁死，或许你已经有过这样的痛苦经历。只要稍微想想便会明白， 1 6位的Wi n d o w s是如此脆弱，它依赖于应用程序的运行情况，并且不允许程序陷入死循环或无穷递归以及任何封闭状态。这是因为所有的应用程序都必须协助Wi n d o w s工作，这种工作类型被称为协作式多任务系统。

 

11.1.2   在Delphi程序中使用多线程

  对一个Wi n d o w s程序员来说，线程提供了非常大的好处。可以在应用程序中的任何地方创建多个附属线程，它们在后台进行各种类型的处理。例如：在一个电子表格程序中计算单元格，或是脱机打印Wo r d文档。即使后台正在处理许多工作，也不会影响前台的用户界面。大多数V C L在被设计时，都只考虑了在任何时刻只有一个线程来访问它。其局限性尤其体现在V C L的用户界面部分。同时，一些非用户界面部分也不是线程安全的。

 

1. 非用户界面的V C L

  实际上V C L只有很少的部分保证是线程安全的。可能在这很少的部分中，最让人注意的是 V C L的属性流机制。V C L的流机制确保了组件流能被多线程安全地读写。请记住即使最基础的 V C L类(诸如T L i s t )，也不是为安全地同时操作多个线程而设计的。对某些情况， V C L提供了一些线程安全的替代，比如，用TThreadList 来替代T L i s t可以解决多个线程操作的问题。

 

2. 用户界面的V C L

  V C L要求所有的用户界面控制要发生在一个应用程序的主线程的环境中 (线程安全的T C a n v a s类除外，本章后面就此将说明)。当然，利用技术手段是可以有效地利用附属线程更新用户界面的 (后面将会讨论)。本章的例子将介绍一些在D e l p h i程序中使用多线程的方法。

 

11.1.3   关于线程的滥用

  好事太多也可能会是件坏事，线程正是这样。从程序设计的角度看，尽管线程能帮助我们解决一些问题，但同时它又带来新的问题。例如，在编写一个集成开发环境时，也许想使编译器在一个专门的线程中运行，这样才能使你在编译时照常做其他的工作。可问题是，如果正在编译时修改了一个文件，会出现什么情况呢？为解决这个问题，你可以临时复制那个文件的副本，或者干脆禁止用户在编译期间修改尚未编译的文件。这说明，线程可以解决一些问题，但同时也带来了其他问题。一个更为严重的问题是多线程依赖于时间片，在多线程中的缺陷非常难以调试。同时，编写和实现线程安全的代码也比较困难，程序员需要考虑很多的因素。