下载
第11章 编写多线程应用程序
本章内容: 对线程的解释 TThread 对象 管理多线程 一个多线程的示范程序 多线程与数据库 多线程与图形处理 Win32操作系统提供了在应用程序中执行多线程的能力.从 16位的Windows升级到Win32的一个最 大受益便是:它允许多线程同时运行.这也是要升级到 32位Delphi的一个最主要的原因.本章提供了 程序中如何进行多线程编程的所有细节.
11.1 对线程的解释
如同在第3章"Win32 API"中所讨论过的,线程是一种操作系统对象,它表示在进程中代码的一 条执行路径.在每一个 Wi n 3 2的应用程序中都至少有一个线程,它通常被称为主线程或默认线程.在 应用程序中也可以自由地创建别的线程去执行其他任务. 线程技术使不同的代码可以同时运行.当然,只有在多 CPU的计算机上,多个线程才能够真正地 同时运行.然而,由于操作系统把 CPU的时间分成很短的片段分配给每个线程,这样给人的感觉好像 是多个线程真的同时运行. 提示 线程不能也从来没有被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下,程序员必须保证应用程序能够把控制权返还给 Windows.如果这一步失败,将 导致整个操作环境锁死,或许你已经有过这样的痛苦经历.只要稍微想想便会明白, 16位的Windows 是如此脆弱,它依赖于应用程序的运行情况,并且不允许程序陷入死循环或无穷递归以及任何封闭状 态.这是因为所有的应用程序都必须协助 Windows工作,这种工作类型被称为协作式多任务系统. 11.1.2 在Delphi程序中使用多线程 对一个 Windows程序员来说,线程提供了非常大的好处.可以在应用程序中的任何地方创建多个
下载
Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008 For Evaluation Only. 第11章 编写多线程应用程序
305
附属线程,它们在后台进行各种类型的处理.例如:在一个电子表格程序中计算单元格,或是脱机打 印Word文档.即使后台正在处理许多工作,也不会影响前台的用户界面. 大多数 V C L在被设计时,都只考虑了在任何时刻只有一个线程来访问它.其局限性尤其体现在 VCL的用户界面部分.同时,一些非用户界面部分也不是线程安全的. 1. 非用户界面的 VCL 实际上VCL只有很少的部分保证是线程安全的.可能在这很少的部分中,最让人注意的是 VCL的 属性流机制. V C L的流机制确保了组件流能被多线程安全地读写.请记住即使最基础的 V C L类(诸如 TList),也不是为安全地同时操作多个线程而设计的.对某些情况, VCL提供了一些线程安全的替代, 比如,用TThreadList 来替代TList可以解决多个线程操作的问题. 2. 用户界面的VCL VCL要求所有的用户界面控制要发生在一个应用程序的主线程的环境中 (线程安全的 TCanvas类除 外,本章后面就此将说明 ).当然,利用技术手段是可以有效地利用附属线程更新用户界面的 (后面将 会讨论).本章的例子将介绍一些在 Delphi程序中使用多线程的方法. 11.1.3 关于线程的滥用 好事太多也可能会是件坏事,线程正是这样.从程序设计的角度看,尽管线程能帮助我们解决一 些问题,但同时它又带来新的问题.例如,在编写一个集成开发环境时,也许想使编译器在一个专门 的线程中运行,这样才能使你在编译时照常做其他的工作.可问题是,如果正在编译时修改了一个文 件,会出现什么情况呢 为解决这个问题,你可以临时复制那个文件的副本,或者干脆禁止用户在编 译期间修改尚未编译的文件.这说明,线程可以解决一些问题,但同时也带来了其他问题.一个更为 严重的问题是多线程依赖于时间片,在多线程中的缺陷非常难以调试.同时,编写和实现线程安全的 代码也比较困难,程序员需要考虑很多的因素.

下一页