作者:Microsoft公司供稿

Ruediger R. Asche
Microsoft Developer Network技术小组 摘要 　　本文讨论将单线程应用程序重新编写成多线程应用程序的策略。它以Microsoft? Windows? 95和Windows NT?的平台为例，从吞吐量（throughput）和响应方面，与兼容的单线程计算相比较而分析了多线程计算的性能。 介绍 　　在您所能够找到的有关多线程的资料中，多数都是讲述同步概念的。例如，如何串行化（serialize）共享公共数据的线程。这种把重点放在讨论同步上是有意义的，因为同步是多线程编程中不可缺少的一部分。本文则后退了一步（takes a step back），主要讨论有关多线程中很少有人涉及的一面：决定一个计算如何能够被有意义地拆分为多个线程。本文中所使用的示例程序，THRDPERF，在Microsoft? Windows? 95和Windows NT?两个平台之上，针对同一个计算采取串行和并发两种方法分别实现了测试套件（test suite），并从吞吐量和性能两方面来比较它们。 　　本文的第一部分建立了一些有关多线程应用程序的词汇（vocabulary），讨论测试套件的范围，并且介绍了示例程序套件是如何设计的。第二部分讨论测试的结果，并且包括对于多线程应用程序设计的建议。与之相关的文章"Interacting with Microsoft Excel: A Case Study in OLE Automation"讨论有关该示例程序套件的一个有趣的问题，即使用测试集合所获得的数据是如何使用OLE Automation被输入Microsoft Excel中的。 　　如果您是经验丰富的多线程应用程序编程者，您可以跳过介绍部分，而直接到下面的“结果”部分。 多线程词汇 　　很长一段时间以来，您的应用程序一直被使用——它运转出色，是可以信赖的，而且the whole bit——但它十分的迟缓，并且您有如何利用多线程的想法。但是，在开始这样做之前请稍等一会儿，因为这里有许多的陷阱，它们使您相信某种多线程设计是非常完美的，但实际上并不是这样。 　　在您跳至有关要进入的结论之前，首先让我们澄清一下在本文中将不讨论的内容： 在Microsoft Win32?应用程序编程接口(API)下提供多线程访问的库是不同的，但是我们不关注这一问题。示例程序套件，Threadlib.exe，是在一个Microsoft Foundation Class Library (MFC)应用程序中使用Win32多线程API来编写的，但是，您是使用Microsoft C运行时(CRT)库、MFC库，还是单纯的（barebones）Win32 API来创建和维持线程，我们并不关心。 　　实际上，每一种库最后都要调用Win32系统服务CreateThread来创建一个工作线程，并且多线程本身总是要通过操作系统来执行。您想要使用哪一种包装机制将不会影响本文的论题。当然，您是使用某一个还是使用其它的包装库（wrapper library），可能会引起性能上的差异，但是在这儿，我们主要讨论多线程的本质，而不关心其包装(wrapper)。 本文所讨论的是在单处理器机器上运行的多线程应用程序。多处理器计算机则是一个完全不同的主题，并且本文中所讨论的结论，几乎没有一个可以应用于多处理器的机器中。我还没有这样的机会在一个运行Windows NT系统的可调整的（scalable）对称多线程(SMP)机器上执行该示例。如果您有这样的机会，我非常高兴地希望知道您的结果。 在本文中，我更喜欢一般性地引用“计算”。计算被定义为您的应用程序的一个子任务，可以被作为整体或部分来执行，可以早于或迟于另一个计算，或者与其他的计算同时发生。例如，让我们假设某个应用程序需要用户的数据，并且需要保存这些数据到磁盘。我们可以假定输入数据包含一种计算，而保存这些数据则是另一种计算。根据应用程序的计算的设计，下面两种情况都是可能的：一种是数据的保存和新数据的输入是同时交叉进行的；另一种是直到用户已经输入了全部的数据才可是将数据保存到磁盘上。第一种情况一般可以使用某种形式的多线程来实现；我们称这种组织计算的方式为并发或交互。后一种情况一般可以用单线程应用程序来实现，在本文中，它被称为串行执行。 有关并发应用程序的设计是一个非常复杂的过程。一般非常有钱的（who make a ton of money）人比较喜欢它，因为要计算出一个给定的任务采用并发执行到底有多大的好处，通常需要多年的研究。本文并不想要教您如何设计多线程应用程序。相反，我要向您指出某些多线程应用程序设计的问题所在，而且，我使用真实（real-life）的性能测试来讨论我的例子。在阅读过本文后，您应该能够观察一个给定的设计，并且能够决定某种设计是否提高了该应用程序的整体性能。 多线程应用程序设计步骤中的一部分工作，就是要决定在何处存在可能潜在地引起数据毁坏的多线程数据访问冲突，以及如何使用线程的同步来避免这种冲突。这项任务（以后，本文将称之为线程编序（thread serialization））是许多有关多线程的文章的主题，（例如，MSDN Library中的"Synchronization on the Fly"或"Compound Win32 Synchronization Objects"），在本文中将丝毫不涉及对它的讨论。有关在本文中要讨论的，我们将假定需要并发的计算并不共享任何数据，并且因此而不需要任何线程编序。这种约定看起来可能有点苛刻，但是请您牢记，不可能有关于同步多线程应用程序的“通用”的讨论，因为每一次编序都将强加一个唯一的“等待-醒来”结构（waiting-and-waking pattern）到已编序的线程，它将直接地影响性能。Win32下的大多数输入/输出(I/O)操作有两种形态：同步或异步。已经被证明在许多的情况下，一个使用同步I/O的多线程设计可以被使用异步单线程I/O的设计来模拟。本文并不讨论作为多线程替代形式的异步单线程I/O，但是，我建议您最好两种设计都考虑。 　　注意到Win32 I/O系统设计的方式是提供一些机制，使得异步I/O要优于同步I/O（例如，I/O全能端口（completion ports））。我计划在以后的文章中讨论有关同步I/O和异步I/O的问题。 正如在"Multiple Threads in the User Interface"一文中所指出的，多线程和图形用户界面(GUI)不能很好地共同工作。在本文中，我假设后台线程可以执行其工作而根本不需要使用Windows GUI；我所处理的这种类型的线程仅仅是“工作线程”，它仅在后台执行计算，而不需要与用户的直接交互。 有有限计算，同样也有与之相对应的无限计算。服务器端应用程序中的一个“倾听”线程就是无限计算的一个例子，它没有任何的目的，只是等待一个客户连接到服务器。在一个客户已经连接之后，该线程就发送一个通知到主线程，并且返回到“倾听”状态，直到下一个客户的连接。很自然，这样的一种计算不可能驻留在同一个作为应用程序用户界面(UI)的线程之中，除非使用一种异步I/O操作。（请注意，这个特定的问题能够，也应该通过使用异步I/O和全能（completion）端口来解决，而不是使用多线程，我在这里使用这个例子仅仅是用作演示）。在本文中，我将只考虑有限计算，就是说，应用程序的子任务将在有限的时间段之后结束。 基于CPU的计算和基于I/O的计算 　　对于一个单个的线程，决定所给定的计算是否是一个优秀的方案的最重要因素是，该计算是一个基于CPU的计算还是基于I/O的计算。基于CPU的计算是指这种计算的大多数时间CPU都非常“忙”。典型的基于CPU的计算如下： 复杂的数学计算，例如复数的计算、图形的处理、或屏幕后台图形计算 对驻留在内存中的文件图像的操作，例如在一个文本文件的内存镜像中的给定字符串。 　　相比较而言，基于I/O的计算是这样的一种计算，它的大多数时间要花费在等待I/O请求的结束。在大多数的操作系统中，正在进入的设备I/O将被异步地处理，可能是由一个专门的I/O处理器来处理，或由一个有效率的中断处理程序来处理，并且，来自于某个应用程序的I/O请求将会挂起调用线程，直到I/O结束。一般来说，花费大部分时间来等待I/O请求的线程不会与其他的线程争夺CPU时间；因此，同基于CPU的线程相比，基于I/O的计算可能不会降低其他线程的性能，（稍后，我将解释这一论点） 　　但是请注意，这种比较是非常理论性的。大多数的计算都不是纯粹的基于I/O的或纯粹的基于CPU的，而是基于I/O的计算和基于CPU的计算都包含。同一集合的计算可能在一种方案中使用顺序计算而运行良好，而在另一种方案中使用并发的计算，这取决于基于CPU的计算和基于I/O的计算的相对划分。 多线程设计的目标 　　在想要对您的应用程序应用多线程之前，您应该问问自己这种转变的目标是什么。多线程有许多潜在的优点： 增强的性能 增强的容量(throughput) 更好地用户快速响应(responsiveness) 　　让我们依次讨论上面的每一个优点。 性能 　　考虑到时间，让我们简单地定义“性能”就是给定的一个或一组计算所消耗的全部时间。按照其定义，则性能的比较就仅仅是对有限计算而言的。 　　无论您相信与否，多线程方案对应用程序的性能的提高是非常有限的。这里面的原因不是很明显，但是它非常有道理： 除非是该应用程序运行于一个多处理器的机器上，（在这种情况下，子计算真正地是并行执行的），基于CPU的计算在多线程情况下不可能比在单线程情况下的执行速度快。这是因为，无论计算被分解成小块（在多线程的情况下）或大块（在同一线程中计算按顺序挨个执行的情况下），只有一个CPU，而且它必需执行所有的计算。结果是，对于一组给定的计算，如果是以多个线程来执行，那么一般会比按串行方式计算完成的时间要长，因为它增加了创建线程和在线程之间切换CPU的额外负担。 一般来说，必定会有某些情况，无论多个计算的完成谁先谁后，但是它们的结果必需同步。例如，使用多个线程来并发的读多个文件到内存中，那么文件被处理的顺序我们是不关心的，但是必需等到所有的数据都读入内存之后，应用程序才能开始处理。我们将在“容量”一节讨论这个想法。 　　在本文中，我们将以消耗的时间，即完成所有的计算所消耗的总的时间，来衡量性能。 容量(Throughput) 　　容量（或响应），是指每一个计算的平均处理周期(turnaround)的时间。为了演示容量，让我们假设一个超级市场的例子（它总是一个有关操作系统的极好的演示工具）：假设每一个计算就是一个在结算柜台被服务的顾客。对于超级市场来说，既可以为每一个顾客开设一个结算柜台，也可以把所有的顾客集中起来通过一个结算柜台。为了我们分析的需要，假设是有多个结算柜台的情况，但是，仅有一个收银员（可怜的家伙！）来服务所有的顾客，而不考虑顾客是在一个柜台前排队或多个柜台前排队。这个超级收银员将高速地从一个柜台跳到下一个柜台，一次仅处理(ringing up)一个顾客的一件商品，然后，就移动到下一个顾客。这个超级的收银员就象是被多个计算所割裂的CPU。 　　就象我们在前面的“性能”一节中所看到的，服务所有顾客的总的时间并没有因为有多个结算柜台打开而减少，因为无论顾客是在一个柜台还是多个柜台被服务，总是这一个收银员来完成所有的工作。但是，事情是这样，同只有一个结算柜台相比，顾客还是喜欢这种超级收银员的方式。这是因为一般情况下，顾客的手推车里的商品数的差别是巨大的，某些顾客的手推车中有一大堆的商品，而某些顾客则只想买很少几件商品。如果您曾经只希望买一盒granola bars和一夸脱牛奶，而却排在某个来为全家24口人采购的先生后面，那您就知道我说的是意味着什么了。 　　无论怎样，如果您能够被Clark Kent先生以高速度服务，而不是在那里排队，您就不会太在意完成结帐的时间是否稍长，因为不管怎么样，两件商品都会很快地被处理完。而满载着为24口人采购的商品的手推车是在另一个柜台被处理的，所以您可以很快就完成结帐而离开。 　　因此，容量就是度量在一个给定的时间内有多少个计算可以被执行。每一个计算是这样度量它的进程的，那就是要比较以下的两个时间：完成本计算花费了多少的时间，以及假设该计算被首先处理的话要花费多少时间。换句话说，如果您去了超级市场，并且希望两分钟就离开那里，但是实际上您花费了两个小时来为您的两件商品结算，原因是您排在了购买其1997生产线的Betty Crocker的后面，那么不得不说，您的进程非常失败。 　　在本文中，我们这样定义一个计算的响应时间，计算完成所消耗的时间除以预计要消耗的时间。那么，如果一个应该消耗10毫秒(ms)的计算，而实际上消耗了20 ms，那么它的响应处理周期就是2，但是，如果就是同一个计算，却消耗了200 ms（可能是因为有另一个长的计算与之竞争并优先）才结束，那么响应处理周期就是20。显然，响应处理周期是越短越好。 　　我们在后面将会看到，在将多线程引入一个应用程序中时，即使导致了整体性能的下降，容量仍然可能是一个有实际意义的因素；但是，要使容量成为一个有实际意义的因素，必需满足下面的一些条件： 每一个计算必需是相互独立的，只要计算一结束，任何计算的结果都可以被处理或使用。如果您是某个大学足球队的队员，而且您们每一个队员都在同一个超级市场买自己的旅行食品，那么您的商品是先被处理还是后被处理、您花费了多长的时间为两件商品结帐、以及您为此等待了多长的时间，这些都无关紧要，因为最后您的汽车是不会离开的，除非所有的队员都买完了食品。所不同的只是您的等待时间，要么是花费在排队等待结帐，要么是如果超级收银员已经为您服务，时间就花费在等待其他人上。 　　这一点很重要，但却常被忽略。就象我前面所提到的，大多数的应用程序迟早都会显式或隐式地同步其计算。例如，如果您的应用程序从不同的文件并发地收集数据，您可能会想要在屏幕上显示结果，或者把它们保存到另一个文件中。在前面一种情况下（在屏幕上显示结果），您应该意识到，大多数图形系统都执行某种的内部批处理或串行操作，除非所有的输出数据都已收集到，否则是根本不会有好的显示的；在后面的情况下，（保存结果到另一个文件），除非整个原型文件已被写入完毕，一般不是您的应用程序（或其他的应用程序）所能完全处理的。所以，如果某个人或某些东西以某种形式将结果顺序化了，不管是应用程序、操作系统、甚至是用户，那么您在处理文件时所能得到的好处可能就会消失了。 计算之间在量上必需有明显的差异。如果超级市场中的每一个顾客都只有两件商品需要结帐，则超级收银员方式一点优势都没有；如果他不得不在3个结算柜台之间跳来跳去，而每一个要被服务的顾客仅有2个（或3个、4个或n个）商品要结算，那么每一个顾客都不得不等待几倍的时间来完成他或她的结算，这比让所有的顾客在一起排队还要糟糕。在这里把多线程想象为shock吸收装置：短的计算并不会冒被排在长的计算之后的危险，但是它们被分成线程并且花费了更多的时间，而本来它们可以在更短的时间内完成。 如果计算的长短可以事先决定，那么串行处理可能比多线程处理要好，您只要简单地以时间长短按升序排列计算就可以了。在超级市场的例子中，就相当于按照顾客的商品数来站排（Express Lane方案的一种变种），这种想法是基于这样的考虑，只有很少的商品的顾客很喜欢它，因为他们不会为一点的事情而耽误很多的时间， 而那些有很多货物的顾客也不会在意，因为无论如何要完成其所有的结算都要花费很长的时间，而且在他们前面的每一个人的商品都比它少。 　　如果只是大致知道计算时间的一个范围，但是您的应用程序不能排序这些计算，那么您应该花些时间做一次最坏情况的分析。在这样的分析中，您应该假定这些计算不是按照时间的升序顺序来排序的，相反，它们是按照时间的降序来排序的。从响应这个角度来讲，这中方案是最坏的情形，因为按照前面所定义的公式，每一个计算都将具有其最高可能的响应处理周期。 快速响应(Responsiveness) 　　我将在这里讨论的、应用程序多线程化的最后一个准则是快速响应（在语言上与响应非常接近，足以使您迷惑不解）。在本文中，如果一个应用程序的设计是保证用户总是能够在一个很短的时间（很短的时间指时间非常短，使得用户感觉不到应用程序被挂起）内完成与应用程序的交互，那么我们就简单一点，定义该应用程序为响应快速的应用程序。 　　对于一个带有GUI的Win32应用程序，快速响应可以被很简单地实现，只要确保长的计算被委托给后台线程，但是实现快速响应所要求的结构可能要求较高的技巧，正如我前面所提到的，某些人可能会等待某个计算在某个时间返回，所以在后台执行一个长的计算可能需要改变用户界面（例如，需要添加一个“取消”按钮，并且依赖该计算结果的菜单项也不得不变灰）。 　　除了性能、容量和快速响应之外，其他的一些原因也可能影响多线程设计。例如，在某些结构下，必需让计算以一种伪随机方式（脑海中再次出现的例子是Bolzmann机器类型的神经网络，在这种网络中，仅当该网络中的每一个节点异步执行其计算时，该互联网络的预期行为才能够工作）。但是，在本文中，我将把讨论的范围限制在上面所涉及的三个因素，那就是：性能、容量和快速响应。 测试的实现 　　我曾经听说过许多关于抽象(abstraction)机制的讨论，说它封装了所有多线程的糟糕(nasty)方面到一个C++对象中，并且因此使一个应用程序获得了多线程的全部优点，而不是缺点。 　　在本文中，我一开始就设计这样一个抽象。我将为一个C++的类ConcurrentExecution定义一个原型，该类将含有成员函数例如：DoConcurrent和DoSerial，并且这两个成员函数的参数将是一个普通对象数组和一个回调函数数组，这些回调函数将被每一个对象并发或串行地调用。该C++类将封装所有关于保持该线程和内部数据结构的真实(gory)细节。 　　但是，对我来说，从一开始我就十分清楚，这样的一个抽象的用处十分有限，因为在设计一个多线程应用程序时的最大量的工作成了一个无法自动完成的任务，这个工作就是决定如何实现多线程。ConcurrentExecution的第一个限制是回调函数将不允许显式或隐式的共享数据；或回调函数需要任何其他形式的同步操作，而这些同步操作将立刻牺牲掉所有该抽象所带来的优点，并且打开所有“精彩”的同步世界中的陷阱和圈套，例如死锁、竞争冲突、或需要非常复杂的复合同步对象。 　　同样，也不允许那些可能潜在地被并发执行的计算来调用UI，因为就象我前面所讲到的，Win32 API对于调用UI的线程强迫了许多个隐式的同步操作。请注意，还有许多其他的API子集和库对于共享它们的线程强迫了隐式的同步操作。 　　这些的限制使ConcurrentExecution只具有极其有限的功能，说具体一点，就是一个管理纯粹工作者线程的抽象（完全独立的计算大多数情况下仅限于在非连续内存区域的数学计算）。 　　然而，事实证明实现ConcurrentExecution类并且在性能测试中使用它是非常有用的，因为，当我实现了该类，并且设计和运行了该测试之时，许多关于多线程的隐藏起来的细节都暴露出来了。请清楚以下一点，虽然ConcurrentExecution类可以使多线程更容易处理，但是如果想要在商业产品中使用它，那么该类的实现还需要一些其他的工作。特别要提到的一点时，我忽略了所有的错误情况处理，这是不可忍受的。但是我假定只用于测试时（我明显地使用了ConcurrentExecution），错误不会出现。ConcurrentExecution类 下面是ConcurrentExecution类的原型：class ConcurrentExecution

{

< private members omitted>

public:

ConcurrentExecution(int iMaxNumberOfThreads);

~ConcurrentExecution();

int DoForAllObjects(int iNoOfObjects,long *ObjectArray,

CONCURRENT_EXECUTION_ROUTINE pObjectProcessor,

CONCURRENT_FINISHING_ROUTINE pObjectTerminated);

BOOL DoSerial(int iNoOfObjects, long *ObjectArray,

CONCURRENT_EXECUTION_ROUTINE pObjectProcessor,

CONCURRENT_FINISHING_ROUTINE pObjectTerminated);

}; 该类是从Thrdlib.dll库中导出的，而Thrdlib.dll库是示例测试套件THRDPERF中的一个工程。在讨论该类的内部结构之前，让我们首先讨论成员函数的语义（semantics）：ConcurrentExecution::ConcurrentExecution(int iMaxNumberOfThreads)

{

m_iMaxArraySize = min(iMaxNumberOfThreads, MAXIMUM_WAIT_OBJECTS);

m_hThreadArray = (HANDLE *)VirtualAlloc(NULL,m_iMaxArraySize*sizeof(HANDLE),

MEM_COMMIT,PAGE_READWRITE);

m_hObjectArray = (DWORD *)VirtualAlloc(NULL,m_iMaxArraySize*sizeof(DWORD),

MEM_COMMIT,PAGE_READWRITE);

//当然，一个真正的实现必需在这里提供对错误的处理...

}; 您可能会注意到构造函数ConcurrentExecution有一个数字参数。该参数指定了该类的实例所支持的“并发的最大度数”；换句话说，如果某个ConcurrentExecution的实例被创建时，n是它的一个参数，那么在任何给定的时间不能有超过n个计算在执行。根据我们以前的分析，该参数就意味“无论有多少个顾客在等待，打开的结算柜台数不要多于n个”。int DoForAllObjects(int iNoOfObjects,long *ObjectArray,

CONCURRENT_EXECUTION_ROUTINE pObjectProcessor,

CONCURRENT_FINISHING_ROUTINE pObjectTerminated); 　　这是在这里被实现的唯一有趣的成员函数。DoForAllObjects的主要参数是一个对象的数组、一个处理器函数、和一个终结器函数。关于对象完全没有强制的格式；每次该处理器被调用时，将有一个对象被传递给它，而且完全由该处理器来解释对象。第一个参数iNoOfObjects，仅仅是要ConcurrentExecution知道在对象数组中的元素数。请注意，在调用DoForAllObjects时，如果对象数组的长度为1，那么它与调用CreateThread就非常相似（有一点不同，那就是CreateThread不接受一个终结器参数）。 　　DoForAllObjects的语义如下：处理器将为每一个对象而调用。对象被处理的顺序并未指定；所有能够担保的只是每一个对象都将在某个时间被传递给处理器。并发的最大度数是由传递给ConcurrentExecution对象的构造函数的参数来决定的。 　　处理器函数不能访问共享的数据，并且不能调用到UI或做任何其他需要显式或隐式地串行操作的事情。目前，仅存在一个处理器函数能够对所有的对象工作；但是，要使用处理器数组来替代该处理器参数将是简单的。 该处理器的原型如下：typedef DWORD (WINAPI *CONCURRENT_EXECUTION_ROUTINE)

(LPVOID lpParameterBlock); 　　当该处理器已经完成了在一个对象上的工作之后，终结器函数将立即被调用。与处理器不同，终结器函数是在该调用函数的环境中被串行调用的，并且可以调用所有的例程和访问调用程序所能够访问的所有数据。但是，应该要注意的是，终结器应该被尽可能地优化，因为终结器中的长计算会影响DoForAllObjects的性能。请注意，尽管只要处理器结束了每一个对象终结器就会立即被调用，直到最后一个对象已经被终结之前，DoForAllObjects本身并没有返回。 　　我们为什么要经历这么多使用终结器的痛苦？我们同样可以让每一个计算在处理器函数的最终结束时执行终结器代码，是吗？ 这样基本上是可以的；但是，有必要强调终结器是在调用DoForAllObjects的线程环境中被调用的。这样的设计使在每一个计算进入时处理它们的结果更加容易，而无须担心同步问题。 终结器函数的原型如下：typedef DWORD (WINAPI *CONCURRENT_FINISHING_ROUTINE)

(LPVOID lpParameterBlock,LPVOID lpResultCode); 　　第一个参数是被处理的对象，第二个参数是处理器函数在该对象上的结果。 　　DoForAllObjects的同类是DoSerial，DoSerial与DoForAllObjects具有相同的参数列表，但是计算是被以串行的顺序处理的，并且以列表中的第一个对象开始。

作者:Microsoft公司供稿

Ruediger R. Asche
Microsoft Developer Network技术小组ConcurrentExecution的内部工作 　　请注意：本节的讨论是非常技术性的，所以假设您理解很多有关Win32线程API的知识。如果您对如何使用ConcurrentExecution类来收集测试数据更加感兴趣，而不是对ConcurrentExecution::DoForAllObjects是如何被实现的感兴趣，那么您现在就可以跳到下面的“使用ConcurrentExecution来试验线程性能”一节。 　　让我们从DoSerial开始，因为它很大程度上是一个“不费脑筋的家伙”：BOOL ConcurrentExecution::DoSerial(int iNoOfObjects,long *ObjectArray,

CONCURRENT_EXECUTION_ROUTINE pProcessor,

CONCURRENT_FINISHING_ROUTINE pTerminator)

{

for (int iLoop=0;iLoop<iNoOfObjects;iLoop++)

{

pTerminator((LPVOID)ObjectArray[iLoop],(LPVOID)pProcessor((LPVOID)ObjectArray[iLoop]));

};

return TRUE;

}; 　　这段代码只是循环遍历该数组，在每一次迭代中调用处理器，然后在处理器和对象本身的结果上调用终结器。干得既干净又漂亮，不是吗？ 　　令人感兴趣的成员函数是DoForAllObjects。乍一看，DoForAllObjects所要做的也没有什么特别的——请求操作系统创建为每一个计算一个线程，并且确保终结器函数能够被正确地调用。但是，有两个问题使得DoForAllObjects比它的表面现象要复杂：第一，当计算的数目多于可用的线程数时，ConcurrentExecution的一个实例所创建的“并发的最大度数”参数可能需要一些附加的记录(bookkeeping)。第二，每一个计算的终结器函数都是在调用DoForAllObjects的线程的上下文中被调用的，而不是在该计算运行所处的线程上下文中被调用的；并且，终结器是在处理器结束之后立刻被调用的。要处理这些问题还是需要很多技巧的。 　　让我们深入到代码中，看看究竟是怎么样的。该段代码是从文件Thrdlib.cpp中继承来的，但是为了清除起见，已经被精简了：int ConcurrentExecution::DoForAllObjects(int iNoOfObjects,long *ObjectArray,

CONCURRENT_EXECUTION_ROUTINE pObjectProcessor,

CONCURRENT_FINISHING_ROUTINE

pObjectTerminated)

{

int iLoop,iEndLoop;

DWORD iThread;

DWORD iArrayIndex;

DWORD dwReturnCode;

DWORD iCurrentArrayLength=0;

BOOL bWeFreedSomething;

char szBuf[70];

m_iCurrentNumberOfThreads=iNoOfObjects;

HANDLE *hPnt=(HANDLE *)VirtualAlloc(NULL,m_iCurrentNumberOfThreads*sizeof(HANDLE)

,MEM_COMMIT,PAGE_READWRITE);

for(iLoop=0;iLoop<m_iCurrentNumberOfThreads;iLoop++)

hPnt[iLoop] = CreateThread(NULL,0,pObjectProcessor,(LPVOID)ObjectArray[iLoop],

CREATE_SUSPENDED,(LPDWORD)&iThread); 　　首先，我们为每一个对象创建单独的线程。因为我们使用CREATE_SUSPENDED来创建该线程，所以还没有线程被启动。另一种方法是在需要时创建每一个线程。我决定不使用这种替代的策略，因为我发现当在一个同时运行了多个线程的应用程序中调用时，CreateThread调用是非常浪费的；这样，同在运行时创建每一个线程相比，在此时创建线程的开销将更加容易接受，for (iLoop = 0; iLoop < m_iCurrentNumberOfThreads; iLoop++)

{

HANDLE hNewThread;

bWeFreedSomething=FALSE;

//如果数组为空，分配一个slot和boogie。if (!iCurrentArrayLength)

{

iArrayIndex = 0;

iCurrentArrayLength=1;

}

else

{

//首先，检查我们是否可以重复使用任何的slot。我们希望在查找一个新的slot之前首先//做这项工作，这样我们就可以立刻调用该就线程的终结器...

iArrayIndex=WaitForMultipleObjects(iCurrentArrayLength,

m_hThreadArray,FALSE,0);

if (iArrayIndex==WAIT_TIMEOUT) // no slot free...

{

{

if (iCurrentArrayLength >= m_iMaxArraySize)

{

iArrayIndex= WaitForMultipleObjects(iCurrentArrayLength,

m_hThreadArray,FALSE,INFINITE);

bWeFreedSomething=TRUE;

}

else //我们可以释放某处的一个slot，现在就这么做...

{

iCurrentArrayLength++;

iArrayIndex=iCurrentArrayLength-1;

}; // Else iArrayIndex points to a thread that has been nuked

};

}

else bWeFreedSomething = TRUE;

}; //在这里，iArrayIndex包含一个有效的索引以存储新的线程。hNewThread = hPnt[iLoop];

ResumeThread(hNewThread);

if (bWeFreedSomething)

{

GetExitCodeThread(m_hThreadArray[iArrayIndex],&dwReturnCode); //错误CloseHandle(m_hThreadArray[iArrayIndex]);

pObjectTerminated((void *)m_hObjectArray[iArrayIndex],(void *)dwReturnCode);

};

m_hThreadArray[iArrayIndex] = hNewThread;

m_hObjectArray[iArrayIndex] = ObjectArray[iLoop];

}; //循环结束 　　DoForAllObjects的核心是hPnt，它是一个对象数组，这些对象是当ConcurrentExecution对象被构造时分配的。该数组能够容纳最大数目的线程，此最大数目与在构造函数中指定的最大并发度数相对应；因此，该数组中的每一个元素都是一个"slot"，并有一个计算居于之中。 　　关于决定如何填充和释放的slots算法如下：该对象数组是从头到尾遍历的，并且对于每一个对象，我们都做如下的事情：如果尚未有slot已经被填充，我们使用当前的对象来填充该数组中的第一个slot，并且继续执行将要处理当前对象的线程。如果至少有一个slot被使用，我们使用WaitForMultipleObjects函数来决定是否有正在运行的任何计算已经结束；如果是，我们在该对象上调用终结器，并且为新对象“重用”该slot。请注意，我们也可以首先填充每一个空闲的slot，直到没有剩余的slots为止，然后开始填充空的slot。但是，如果我们这样做了，那么空出slot的终结器函数将不会被调用，直到所有的slot都已经被填充，这样就违反了我们有关当处理器结束一个对象时，终结器立刻被调用的要求。 　　最后，还有没有空闲slot的情况（就是说，当前激活的线程数等于ConcurrentExecution对象所允许的最大并发度数）。在这种情况下，WaitForMultipleObjects将被再次调用以使得DoForAllObjects处于“睡眠”状态，直到有一个slot空出；只要这种情况一发生，终结器就被在空出slot的对象上调用，并且工作于当前对象的线程被继续执行。 　　终于，所有的计算要么都已经结束，要么将占有对象数组中的slot。下列的代码将会处理所有剩余的线程：iEndLoop = iCurrentArrayLength;

for (iLoop=iEndLoop;iLoop>0;iLoop--)

{

iArrayIndex=WaitForMultipleObjects(iLoop, m_hThreadArray,FALSE,INFINITE);

if (iArrayIndex==WAIT_FAILED)

{

GetLastError();

_asm int 3; //这里要做一些聪明的事...

};

GetExitCodeThread(m_hThreadArray[iArrayIndex],&dwReturnCode); //错误？if (!CloseHandle(m_hThreadArray[iArrayIndex]))

MessageBox(GetFocus(),"Can't delete thread!","",MB_OK); //使它更好...

pObjectTerminated((void *)m_hObjectArray[iArrayIndex],

(void *)dwReturnCode);

if (iArrayIndex==iLoop-1) continue; //这里很好，没有需要向后填充m_hThreadArray[iArrayIndex]=m_hThreadArray[iLoop-1];

m_hObjectArray[iArrayIndex]=m_hObjectArray[iLoop-1];

}; 最后，清除：if (hPnt) VirtualFree(hPnt,m_iCurrentNumberOfThreads*sizeof(HANDLE),

MEM_DECOMMIT);

return iCurrentArrayLength;

}; 使用ConcurrentExecution来试验线程性能 　　性能测试的范围如下：测试应用程序Threadlibtest.exe的用户可以指定是否测试基于CPU的或基于I/O的计算、执行多少个计算、计算的时间有多长、计算是如何排序的（为了测试最糟的情况与随机延迟），以及计算是被并发执行还是串行执行。 　　为了消除意外的结果，每一个测试可以被执行十次，然后将十次的结果拿来平均，以产生一个更加可信的结果。 　　通过选择菜单选项"Run entire test set"，用户可以请求运行所有测试变量的变形。在测试中使用的计算长度在基础值10和3,500 ms之间变动（我一会儿将讨论这一问题），计算的数目在2和20之间变化。如果在运行该测试的计算机上安装了Microsoft Excel，Threadlibtest.exe将会把结果转储在一个Microsoft Excel工作表，该工作表位于C:\Temp\Values.xls。在任何情况下结果值也将会被保存到一个纯文本文件中，该文件位于C:\Temp\Results.fil。请注意，我对于协议文件的位置使用了硬编码的方式，纯粹是懒惰行为；如果您需要在您的计算机上重新生成测试结果，并且需要指定一个不同的位置，那么只需要重新编译生成该工程，改变文件Threadlibtestview.cpp的开头部分的TEXTFILELOC和SHEETFILELOC标识符的值即可。 　　请牢记，运行整个的测试程序将总是以最糟的情况来排序计算（就是说，执行的顺序是串行的，最长的计算将被首先执行，其后跟随着第二长的计算，然后以次类推）。这种方案牺牲了串行执行的灵活性，因为并发执行的响应时间在一个非最糟的方案下也没有改变，而该串行执行的响应时间是有可能提高的。 　　正如我前面所提到的，在一个实际的方案中，您应该分析每一个计算的时间是否是可以预测的。 　　使用ConcurrentExecution类来收集性能数据的代码位于Threadlibtestview.cpp中。示例应用程序本身(Threadlibtest.exe)是一个真正的单文档界面(SDI)的MFC应用程序。所有与示例有关的代码都驻留在view类的实现CThreadLibTestView中，它是从CEasyOutputView继承而来的。（有关对该类的讨论，请参考"Windows NT Security in Theory and Practice"。）这里并不包含该类中所有的有趣代码，所包含的大部分是其数字统计部分和用户界面处理部分。执行测试中的"meat"在CThreadLibTestView::ExecuteTest中，将执行一个测试运行周期。下面是有关CThreadLibTestView::ExecuteTest的简略代码：void CThreadlibtestView::ExecuteTest()

{

ConcurrentExecution *ce;

bCPUBound=((m_iCompType&CT_IOBOUND)==0); //全局...

ce = new ConcurrentExecution(25);

if (!QueryPerformanceCounter(&m_liOldVal)) return; //获得当前时间。if (!m_iCompType&CT_IOBOUND) timeBeginPeriod(1);

if (m_iCompType&CT_CONCURRENT)

m_iThreadsUsed=ce->DoForAllObjects(m_iNumberOfThreads,

(long *)m_iNumbers,

(CONCURRENT_EXECUTION_ROUTINE)pProcessor,

(CONCURRENT_FINISHING_ROUTINE)pTerminator);

else

ce->DoSerial(m_iNumberOfThreads,

(long *)m_iNumbers,

(CONCURRENT_EXECUTION_ROUTINE)pProcessor,

(CONCURRENT_FINISHING_ROUTINE)pTerminator);

if (!m_iCompType&CT_IOBOUND) timeEndPeriod(1);

delete(ce);

<其他的代码在一个数组中排序结果，以供Excel处理...>

} 　　该段代码首先创建一个ConcurrentExecution类的对象，然后，取样当前时间，（用于统计计算所消耗的时间和响应时间），并且，根据所请求的是串行执行还是并发执行，分别调用ConcurrentExecution对象DoSerial或DoForAllObjects成员。请注意，对于当前的执行我请求最大并发度数为25；如果您想要运行有多于25个计算的测试程序，那么您应该提高该值，使它大于或等于运行您的测试程序所需要的最大并发数。 　　让我们看一下处理器和终结器，以得到精确测量的结果：extern "C"

{

long WINAPI pProcessor(long iArg)

{

PTHREADBLOCKSTRUCT ptArg=(PTHREADBLOCKSTRUCT)iArg;

BOOL bResult=TRUE;

int iDelay=(ptArg->iDelay);

if (bCPUBound)

{

int iLoopCount;

iLoopCount=(int)(((float)iDelay/1000.0)*ptArg->tbOutputTarget->m_iBiasFactor);

QueryPerformanceCounter(&ptArg->liStart);

for (int iCounter=0; iCounter<iLoopCount; iCounter++);

}

else

{

QueryPerformanceCounter(&ptArg->liStart);

Sleep(ptArg->iDelay);

};

return bResult;

}

long WINAPI pTerminator(long iArg, long iReturnCode)

{

PTHREADBLOCKSTRUCT ptArg=(PTHREADBLOCKSTRUCT)iArg;

QueryPerformanceCounter(&ptArg->liFinish);

ptArg->iEndOrder=iEndIndex++;

return(0);

}

} 　　处理器模拟一个计算，其长度已经被放到一个与计算有关的数据结构THREADBLOCKSTRUCT中。THREADBLOCKSTRUCT保持着与计算有关的数据，如其延迟和终止时间（以性能计数“滴答”来衡量），以及反向指针，指向实用化该结构的视图(view)。 　　通过简单的使计算“睡眠”指定的时间就可以模拟基于I/O的计算。基于CPU的计算将进入一个空的for循环。这里的一些注释是为了帮助理解代码的功能：计算是基于CPU的，并且假定其执行时间为指定的毫秒数。在本测试程序的早期版本中，我仅仅是要for循环执行足够多的次数以满足指定的延迟的需求，而不考虑数字的实际含义。（根据相关的代码，对于基于I/O的计算该数字实际意味着毫秒，而对于基于CPU的计算，该数字则意味着迭代次数。）但是，为了能够使用绝对时间来比较基于CPU的计算和基于I/O的计算，我决定重写这段代码，这样无论对于基于CPU的计算还是基于I/O的计算，与计算有关的延迟都是以毫秒测量。 　　我发现对于具有指定的、预先定义时间长度的基于CPU的计算，要编写代码来模拟它并不是一件简单的事情。原因是这样的代码本身不能查询系统时间，因为所引发的调用迟早都会交出CPU，而这违背了基于CPU的计算的要求。试图使用异步多媒体时钟事件同样没有得到满意的效果，原因是Windows NT下计时器服务的工作方式。设置了一个多媒体计时器的线程实际上被挂起，直到该计时器回调被调用；因此，基于CPU的计算突然变成了基于I/O的操作了。 　　于是，最后我使用了一个有点儿低劣的技巧：CThreadLibTestView::OnCreate中的代码执行100次循环从1到100,000计数，并且取样通过该循环所需要的平均时间。结果被保存在成员变量m_iBiasFactor中，该成员变量是一个浮点数，它在处理器函数中被使用来决定毫秒如何被“翻译”成迭代次数。不幸的是，因为操作系统的高度戏剧性的天性，要决定实际上运行一个指定长度的计算要迭代多少次给定的循环是困难的。但是，我发现该策略在决定基于CPU的操作的计算时间方面，完成了非常可信的工作。 注意 如果您重新编译生成该测试应用程序，请小心使用最优化选项。如果您指定了"Minimize execution time"优化，则编译程序将检测具有空的主体的for循环，并且删除这些循环。 　　终结器非常简单：当前时间被取样并保存在计算的THREADBLOCKSTRUCT中。在测试结束之后，该代码计算执行ExecuteTest的时间和终结器为每一个计算所调用的时间之间的差异。然后，所有计算所消耗的时间由所有已完成的计算中最后一个计算完成时所消耗的时间所决定，而响应时间则是每一个计算的响应时间的平均值，这里，每一个响应时间，同样，定义为从测试开始该线程消耗的时间除以该线程的延迟因子。请注意，终结器在主线程上下文中串行化的运行，所以在共享的iEndIndex变量上的递增指令是安全的。 　　这些实际就是本测试的全部；其余的部分则主要是为测试的运行设置一些参数，以及对结果执行一些数学计算。填充结果到Microsoft Excel工作单中的相关逻辑将在"Interacting with Microsoft Excel: A Case Study in OLE Automation."一文中讨论。 结果 　　如果您想要在您的计算机上重新创建该测试结果，您需要做以下的事情： 　　如果您需要改变测试参数，例如最大计算数或协议文件的位置，请编辑THRDPERF示例工程中的Threadlibtestview.cpp，然后重新编译生成该应用程序。（请注意，要编译生成该应用程序，您的计算机需要对长文件名的支持。） 　　请确保文件Thrdlib.dll在一个Threadlibtest.exe能够链接到它的位置。 　　如果您想要使用Microsoft Excel来查看测试的结果，请确定Microsoft Excel已经正确地被安装在运行该测试的计算机上。 　　从Windows 95或Windows NT执行Threadlibtest.exe，并且从“Run performance tests”菜单选择"Run entire test set"。正常情况下，测试运行一次要花费几个小时才能完成。 　　在测试结束之后，检查结果时，既可以使用普通文本协议文件C:\Temp\Results.fil，也可以使用工作单文件C:\Temp\Values.xls。请注意，Microsoft Excel的自动化（automation）逻辑并不自动地为您从原始数据生成图表，我使用了几个宏来重新排列该结果，并且为您生成了图表。我憎恨数字（number crunching），但是我必需称赞Microsoft Excel，因为即使象我一样的工作表妄想狂（spreadsheet-paranoid），也可以提供这样漂亮的用户界面，在几分钟之内把几列数据装入有用的图表。 　　我所展现的测试结果是在一个486/33 MHz的带有16 MB RAM的系统收集而来的。该计算机同时安装了Windows NT (3.51版)和Windows 95；这样，在两个操作系统上的不同测试结果就是可比的了，因为它们基于同样的硬件系统。 　　那么，现在让我们来解释这些值。这里是总结计算结果的图表；后面有其解释。该图表应该这样来看：每一个图表的x轴有6个值（除了有关长计算的消耗时间表，该表仅含有5个值，这是因为在我的测试运行时，对于非常长的计算计时器溢出了）。一个值代表多个计算；我以2、5、8、11、14和17个计算来运行每一个测试。在Microsoft Excel结果工作表中，您将会找到对于基于CPU的计算和基于I/O的计算的线程的每一种计算数目的结果，延迟（delay bias）分别是10 ms、30 ms、90 ms、270 ms,、810 ms和2430 ms，但是在该图表中，我仅包括了10 ms和2430 ms的结果，这样所有的数字都被简化，而且更容易理解。 　　我需要解释"delay bias."的含义，如果一个测试运行的delay bias是n，则每一个计算都有一个倍数n作为其计算时间。例如，如果试验的是delay bias为10的5个计算，则其中一个计算将执行50 ms，第二个将执行40 ms，第三个将执行30 ms，第四个将执行20 ms，而第五个将执行10 ms。并且，当这些计算被串行执行时，假定为最糟的情况，所以具有最长延迟的计算首先被执行，其他的计算按降序排列其后。于是，在“理想”情况下（就是说，计算之间没有重叠），对于基于CPU的计算来说，全部所需的时间将是50 ms + 40 ms + 30 ms + 20 ms + 10 ms = 150 ms。 　　对于消耗时间图表来说，y轴的值与毫秒对应，对于响应时间图表来说，y轴的值与相对（relative turnaround）长度（即，实际执行所花费的毫秒数除以预期的毫秒数）相对应。 图1.短计算消耗时间比较，在 Windows NT下 图2.长计算消耗时间比较，在Windows NT下 图3.短计算响应时间比较，在Windows NT下 图4.长计算响应时间比较，在Windows NT下 图5.短计算消耗时间比较，在Windows 95下 图6.长计算消耗时间比较，在Windows 95下 图7.短计算响应时间比较，在Windows 95下 图8.长计算响应时间比较，在Windows 95下 基于 I/O的任务 　　以消耗时间和turnaround时间来衡量，基于I/O的线程当并发执行时比串行执行要好得多。作为计算得一个功能，对于并发执行来说，消耗时间以线性模式递增，而对于串行执行来说，则以指数模式递增（有关Windows NT请参阅图1和2，有关Windows 95请参阅图5和6）。 　　请注意，这个结论与我们前面对基于I/O的计算的分析是一致的，基于I/O的计算是多线程的优秀候选人，因为一个线程在等待I/O请求结束时被挂起，而这段时间该线程不会占用 CPU时间，于是，这段时间就可以被其他的线程所使用。 　　对于并发计算来说，平均响应时间是一个常数，对于串行计算来说，平均响应时间则线性递增（请分别参阅图3、4、7和8）。 　　请注意无论任何情况，只有少数几个计算执行的方案中，无论串行或并发的执行，无论测试参数如何设置，并没有什么明显的区别。 基于CPU的任务 　　正如我们前面所提到的，在一个单处理器的计算机中，基于CPU的任务的并发执行速度不可能比串行执行速度快，但是我们可以看到，在Windows NT下线程创建和切换的额外开销非常小；对于非常短的计算，并发执行仅仅比串行执行慢10%，而随着计算长度的增加，这两个时间就非常接近了。以响应时间来衡量，我们可以发现对于长计算，并发执行相对于串行执行的响应增益可以达到50%，但是对于短的计算，串行执行实际上比并发执行更加好。Windows 95和Windows NT之间的比较 　　如果我们看一看有关长计算的图表（即，图2、4、6和8），我们可以发现在Windows 95和Windows NT下其行为是极其类似的。请不要被这样的事实所迷惑，即好象Windows 95处理基于I/O的计算与基于CPU的计算不同于Windows NT。我把这一结果的原因归结为这样一个事实，那就是我用来决定多少个测试循环与1毫秒相对应的算法（如前面所述）是非常不精确的；我发现同样是这个算法，在完全相同的环境下执行多次时，所产生的结果之间的差异最大时可达20%。所以，比较基于CPU的计算和基于I/O的计算实际上是不公平的。 　　Windows 95和Windows NT之间不同的一点是当针对短的计算时。如我们从图1和5所看到的，对于并发的基于I/O的短计算，Windows NT的效果要好得多。我把这一结果得原因归结为更加有效率得线程创建方案。请注意，对于长得计算，串行与并发I/O操作之间的差别消失了，所以这里我们处理的是固定的、相对比较小的额外开销。 　　对于短的计算，以响应时间来衡量（如图3和7），请注意，在Windows NT下，在10个线程处有一个断点，在这里更多的计算并发执行有更好的效果，而对于Windows 95，则是串行计算有更好的容量。 　　请注意这些比较都是基于当前版本的操作系统得到的（Windows NT 3.51版和Windows 95），如果考虑到操作系统的问题，那么线程引擎非常有可能被增强，所以两个操作系统之间的各自行为的差异有可能消失。但是，有一点很有趣的要注意，短计算一般不必要使用多线程，尤其是在Windows 95下。 建议 　　这些结果可以推出下面的建议：决定多线程性能的最主要因素是基于I/O的计算和基于CPU的计算的比例，决定是否采用多线程的主要条件是前台的用户响应。 　　让我们假定在您的应用程序中，有多个子计算可以在不同的线程中潜在地被执行。为了决定对这些计算使用多线程是否有意义，要考虑下面的几点。 　　如果用户界面响应分析决定某些事情应该在第二线程中实现，那么，决定将要执行的任务是基于I/O的计算还是基于CPU的计算就很有意义。基于I/O的计算最好被重新定位到后台线程中。（但是，请注意，异步单线程的I/O处理可能比多线程同步I/O要好，这要看问题而定）非常长的基于CPU的线程可能从在不同的线程中被执行获益；但是，除非该线程的响应非常重要，否则，在同一个后台线程中执行所有的基于CPU的任务可能比在不同的线程中执行它更有意义。请记住在任何的情况下，短计算在并发执行时一般会在线程创建时有非常大的额外开销。 　　如果对于基于CPU的计算 — 即每一个计算的结果只要得到了就立刻能应用的计算，响应是最关键的，那么，您应该尝试决定这些计算是否能够以升序排序，在此种情况下这些计算串行执行的整体性能仍然会比并行执行要好。请注意，有一些计算机的体系结构的设计是为了能够非常有效率地处理长的计算（例如矩阵操作），那么，在这样的计算机上对长的计算实行多线程化的话，您可能实际上牺牲了这种结构的优势。 　　所有的这些分析都假定该应用程序是运行在一个单处理器的计算机上，并且计算之间是相互独立的。实际上，如果计算之间相互依赖而需要串行设计，串行执行的性能将不受影响（因为串行是隐式的），而并发执行的版本将总是受到不利的影响。 　　我还建议您基于计算之间相互依赖的程度决定多线程的设计。在大多数情况下子计算线程化不用说是好的，但是，如果对于拆分您的应用程序为多个可以在不同线程处理的子计算的方法有多种选择，我推荐您使用同步的复杂性作为一个条件。换句话说，如果拆分成多个线程而需要非常少和非常直接的同步，那么这种方案就比需要使用大量且复杂的线程同步的方案要好。 　　最后一个请注意是，请牢记线程是一种系统资源，不是无代价的；所以，there may be a greater penalty to multithreading than performance hits alone.作为第一规则（rule of thumb），我建议您在使用多线程时要保持理智并且谨慎。在多线程确实能够给您的应用程序设计带来好处的时候才使用它们，但是，如果串行计算可以达到同样的效果，就不要使用它们。 总结 　　运行附加的性能测试套件产生了一些特殊的结果，这些结果提供了许多有关并发应用程序设计的内部逻辑。请注意我的许多假定是非常基本的；我选择了比较非常长的计算和非常短的计算，我假定计算之间完全独立，要么完全是基于I/O的计算，要么是完全基于CPU的计算。而绝大多数的现实问题，如果以计算长度和boundedness来衡量，都是介于这两种情况之间的。请把本文中的材料仅仅作为一个起点，它使您更加详细地分析您的应用程序，以决定是否使用多线程。 　　在本系列的将来的一篇文章中，我将讨论通过异步I/O来增强基于I/O的操作的性能。

实用技巧

用VC++5.0实 现 多 线 程 的 调 度 和 处 理

一 多 任 务， 多 进 程 和 多 线 程

----Windows95 和WindowsNT 操 作 系 统 支 持 多 任 务 调 度 和 处 理， 基 于 该 功 能 所 提 供 的 多 任 务 空 间， 程 序 员 可 以 完 全 控 制 应 用 程 序 中 每 一 个 片 段 的 运 行， 从 而 编 写 高 效 率 的 应 用 程 序。

----所 谓 多 任 务 通 常 包 括 这 样 两 大 类： 多 进 程 和 多 线 程。 进 程 是 指 在 系 统 中 正 在 运 行 的 一 个 应 用 程 序； 线 程 是 系 统 分 配 处 理 器 时 间 资 源 的 基 本 单 元， 或 者 说 进 程 之 内 独 立 执 行 的 一 个 单 元。 对 于 操 作 系 统 而 言， 其 调 度 单 元 是 线 程。 一 个 进 程 至 少 包 括 一 个 线 程， 通 常 将 该 线 程 称 为 主 线 程。 一 个 进 程 从 主 线 程 的 执 行 开 始 进 而 创 建 一 个 或 多 个 附 加 线 程， 就 是 所 谓 基 于 多 线 程 的 多 任 务。

----开 发 多 线 程 应 用 程 序 可 以 利 用32 位Windows 环 境 提 供 的Win32 API 接 口 函 数， 也 可 以 利 用VC++ 中 提 供 的MFC 类 库 进 行 开 发。 多 线 程 编 程 在 这 两 种 方 式 下 原 理 是 一 样 的， 用 户 可 以 根 据 需 要 选 择 相 应 的 工 具。 本 文 重 点 讲 述 用VC++5.0 提 供 的MFC 类 库 实 现 多 线 程 调 度 与 处 理 的 方 法 以 及 由 线 程 多 任 务 所 引 发 的 同 步 多 任 务 特 征， 最 后 详 细 解 释 一 个 实 现 多 线 程 的 例 程。

二 基 于MFC的 多 线 程 编 程

----1 MFC 对 多 线 程 的 支 持

----MFC 类 库 提 供 了 多 线 程 编 程 支 持， 对 于 用 户 编 程 实 现 来 说 更 加 方 便。 非 常 重 要 的 一 点 就 是， 在 多 窗 口 线 程 情 况 下，MFC 直 接 提 供 了 用 户 接 口 线 程 的 设 计。

----MFC 区 分 两 种 类 型 的 线 程： 辅 助 线 程（Worker Thread） 和 用 户 界 面 线 程(UserInterface Thread)。 辅 助 线 程 没 有 消 息 机 制， 通 常 用 来 执 行 后 台 计 算 和 维 护 任 务。MFC 为 用 户 界 面 线 程 提 供 消 息 机 制， 用 来 处 理 用 户 的 输 入， 响 应 用 户 产 生 的 事 件 和 消 息。 但 对 于Win32 的API 来 说， 这 两 种 线 程 并 没 有 区 别， 它 只 需 要 线 程 的 启 动 地 址 以 便 启 动 线 程 执 行 任 务。 用 户 界 面 线 程 的 一 个 典 型 应 用 就 是 类CWinApp， 大 家 对 类CwinApp 都 比 较 熟 悉， 它 是CWinThread 类 的 派 生 类， 应 用 程 序 的 主 线 程 是 由 它 提 供， 并 由 它 负 责 处 理 用 户 产 生 的 事 件 和 消 息。 类CwinThread 是 用 户 接 口 线 程 的 基 本 类。CWinThread 的 对 象 用 以 维 护 特 定 线 程 的 局 部 数 据。 因 为 处 理 线 程 局 部 数 据 依 赖 于 类CWinThread， 所 以 所 有 使 用MFC 的 线 程 都 必 须 由MFC 来 创 建。 例 如， 由run-time 函 数_beginthreadex 创 建 的 线 程 就 不 能 使 用 任 何MFC API。

----2 辅 助 线 程 和 用 户 界 面 线 程 的 创 建 和 终 止

----要 创 建 一 个 线 程， 需 要 调 用 函 数AfxBeginThread。 该 函 数 通 过 参 数 重 载 具 有 两 种 版 本， 分 别 对 应 辅 助 线 程 和 用 户 界 面 线 程。 无 论 是 辅 助 线 程 还 是 用 户 界 面 线 程， 都 需 要 指 定 额 外 的 参 数 以 修 改 优 先 级， 堆 栈 大 小， 创 建 标 志 和 安 全 特 性 等。 函 数AfxBeginThread 返 回 指 向CWinThread 类 对 象 的 指 针。

----创 建 助 手 线 程 相 对 简 单。 只 需 要 两 步： 实 现 控 制 函 数 和 启 动 线 程。 它 并 不 必 须 从CWinThread 派 生 一 个 类。 简 要 说 明 如 下：

----1. 实 现 控 制 函 数。 控 制 函 数 定 义 该 线 程。 当 进 入 该 函 数， 线 程 启 动； 退 出 时， 线 程 终 止。 该 控 制 函 数 声 明 如 下：

UINT MyControllingFunction( LPVOID pParam );

----该 参 数 是 一 个 单 精 度32 位 值。 该 参 数 接 收 的 值 将 在 线 程 对 象 创 建 时 传 递 给 构 造 函 数。 控 制 函 数 将 用 某 种 方 式 解 释 该 值。 可 以 是 数 量 值， 或 是 指 向 包 括 多 个 参 数 的 结 构 的 指 针， 甚 至 可 以 被 忽 略。 如 果 该 参 数 是 指 结 构， 则 不 仅 可 以 将 数 据 从 调 用 函 数 传 给 线 程， 也 可 以 从 线 程 回 传 给 调 用 函 数。 如 果 使 用 这 样 的 结 构 回 传 数 据， 当 结 果 准 备 好 的 时 候， 线 程 要 通 知 调 用 函 数。 当 函 数 结 束 时， 应 返 回 一 个UINT 类 型 的 值 值， 指 明 结 束 的 原 因。 通 常， 返 回0 表 明 成 功， 其 它 值 分 别 代 表 不 同 的 错 误。

----2. 启 动 线 程。 由 函 数AfxBeginThread 创 建 并 初 始 化 一 个CWinThread 类 的 对 象， 启 动 并 返 回 该 线 程 的 地 址。 则 线 程 进 入 运 行 状 态。

----3. 举 例 说 明。 下 面 用 简 单 的 代 码 说 明 怎 样 定 义 一 个 控 制 函 数 以 及 如 何 在 程 序 的 其 它 部 分 使 用。

UINT MyThreadProc( LPVOID pParam )

{

CMyObject* pObject = (CMyObject*)pParam;

if (pObject == NULL ||

!pObject- >IsKindOf(RUNTIME_CLASS(CMyObject)))

return -1;    //非法参数

……//具体实现内容

return 0;    //线程成功结束

}

//在程序中调用线程的函数

……

pNewObject = new CMyObject;

AfxBeginThread(MyThreadProc, pNewObject);

……

创建用户界面线程有两种方法。

----第 一 种 方 法， 首 先 从CWinTread 类 派 生 一 个 类（ 注 意 必 须 要 用 宏DECLARE_DYNCREATE 和 IMPLEMENT_DYNCREATE 对 该 类 进 行 声 明 和 实 现）； 然 后 调 用 函 数AfxBeginThread 创 建CWinThread 派 生 类 的 对 象 进 行 初 始 化 启 动 线 程 运 行。 除 了 调 用 函 数AfxBeginThread 之 外, 也 可 以 采 用 第 二 种 方 法， 即 先 通 过 构 造 函 数 创 建 类CWinThread 的 一 个 对 象， 然 后 由 程 序 员 调 用 函 数::CreateThread 来 启 动 线 程。 通 常 类CWinThread 的 对 象 在 该 线 程 的 生 存 期 结 束 时 将 自 动 终 止， 如 果 程 序 员 希 望 自 己 来 控 制， 则 需 要 将m_bAutoDelete 设 为FALSE。 这 样 在 线 程 终 止 之 后 类CWinThread 对 象 仍 然 存 在， 只 是 在 这 种 情 况 下 需 要 手 动 删 除CWinThread 对 象。

----通 常 线 程 函 数 结 束 之 后， 线 程 将 自 行 终 止。 类CwinThread 将 为 我 们 完 成 结 束 线 程 的 工 作。 如 果 在 线 程 的 执 行 过 程 中 程 序 员 希 望 强 行 终 止 线 程 的 话， 则 需 要 在 线 程 内 部 调 用AfxEndThread(nExitCode)。 其 参 数 为 线 程 结 束 码。 这 样 将 终 止 线 程 的 运 行， 并 释 放 线 程 所 占 用 的 资 源。 如 果 从 另 一 个 线 程 来 终 止 该 线 程， 则 必 须 在 两 个 线 程 之 间 设 置 通 信 方 法。 如 果 从 线 程 外 部 来 终 止 线 程 的 话， 还 可 以 使 用Win32 函 数（CWinThread 类 不 提 供 该 成 员 函 数）：BOOL TerminateThread(HANDLE hThread,DWORD dwExitcode)。 但 在 实 际 程 序 设 计 中 对 该 函 数 的 使 用 一 定 要 谨 慎， 因 为 一 旦 该 命 令 发 出， 将 立 即 终 止 该 线 程， 并 不 释 放 线 程 所 占 用 的 资 源， 这 样 可 能 会 引 起 系 统 不 稳 定。

----如 果 所 终 止 的 线 程 是 进 程 内 的 最 后 一 个 线 程， 则 在 该 线 程 终 止 之 后 进 程 也 相 应 终 止。

----3 进 程 和 线 程 的 优 先 级 问 题

----在Windows95 和WindowsNT 操 作 系 统 当 中， 任 务 是 有 优 先 级 的， 共 有32 级， 从0 到31， 系 统 按 照 不 同 的 优 先 级 调 度 线 程 的 运 行。

----1) 0-15 级 是 普 通 优 先 级， 线 程 的 优 先 级 可 以 动 态 变 化。 高 优 先 级 线 程 优 先 运 行， 只 有 高 优 先 级 线 程 不 运 行 时， 才 调 度 低 优 先 级 线 程 运 行。 优 先 级 相 同 的 线 程 按 照 时 间 片 轮 流 运 行。 2) 16-30 级 是 实 时 优 先 级， 实 时 优 先 级 与 普 通 优 先 级 的 最 大 区 别 在 于 相 同 优 先 级 进 程 的 运 行 不 按 照 时 间 片 轮 转， 而 是 先 运 行 的 线 程 就 先 控 制CPU， 如 果 它 不 主 动 放 弃 控 制， 同 级 或 低 优 先 级 的 线 程 就 无 法 运 行。

----一 个 线 程 的 优 先 级 首 先 属 于 一 个 类， 然 后 是 其 在 该 类 中 的 相 对 位 置。 线 程 优 先 级 的 计 算 可 以 如 下 式 表 示：

----线 程 优 先 级= 进 程 类 基 本 优 先 级+ 线 程 相 对 优 先 级

----进 程 类 的 基 本 优 先 级：

IDLE_PROCESS_CLASS

NORMAL_PROCESS_CLASS

HIGH_PROCESS_CLASS

REAL_TIME_PROCESS_CLASS

线程的相对优先级：

THREAD_PRIORITY_IDLE

（最低优先级，仅在系统空闲时执行）

THREAD_PRIORITY_LOWEST

THREAD_PRIORITY_BELOW_NORMAL

THREAD_PRIORITY_NORMAL  （缺省）

THREAD_PRIORITY_ABOVE_NORMAL

THREAD_PRIORITY_HIGHEST

THREAD_PRIORITY_CRITICAL

（非常高的优先级）

----4 线 程 同 步 问 题

----编 写 多 线 程 应 用 程 序 的 最 重 要 的 问 题 就 是 线 程 之 间 的 资 源 同 步 访 问。 因 为 多 个 线 程 在 共 享 资 源 时 如 果 发 生 访 问 冲 突 通 常 会 产 生 不 正 确 的 结 果。 例 如， 一 个 线 程 正 在 更 新 一 个 结 构 的 内 容 的 同 时 另 一 个 线 程 正 试 图 读 取 同 一 个 结 构。 结 果， 我 们 将 无 法 得 知 所 读 取 的 数 据 是 什 么 状 态： 旧 数 据， 新 数 据， 还 是 二 者 的 混 合 ？

----MFC 提 供 了 一 组 同 步 和 同 步 访 问 类 来 解 决 这 个 问 题， 包 括：

----同 步 对 象：CSyncObject, CSemaphore, CMutex, CcriticalSection 和CEvent ； 同 步 访 问 对 象：CMultiLock 和 CSingleLock 。

----同 步 类 用 于 当 访 问 资 源 时 保 证 资 源 的 整 体 性。 其 中CsyncObject 是 其 它 四 个 同 步 类 的 基 类， 不 直 接 使 用。 信 号 同 步 类CSemaphore 通 常 用 于 当 一 个 应 用 程 序 中 同 时 有 多 个 线 程 访 问 一 个 资 源（ 例 如， 应 用 程 序 允 许 对 同 一 个Document 有 多 个View） 的 情 况； 事 件 同 步 类CEvent 通 常 用 于 在 应 用 程 序 访 问 资 源 之 前 应 用 程 序 必 须 等 待（ 比 如， 在 数 据 写 进 一 个 文 件 之 前 数 据 必 须 从 通 信 端 口 得 到） 的 情 况； 而 对 于 互 斥 同 步 类CMutex 和 临 界 区 同 步 类CcriticalSection 都 是 用 于 保 证 一 个 资 源 一 次 只 能 有 一 个 线 程 访 问， 二 者 的 不 同 之 处 在 于 前 者 允 许 有 多 个 应 用 程 序 使 用 该 资 源（ 例 如， 该 资 源 在 一 个DLL 当 中） 而 后 者 则 不 允 许 对 同 一 个 资 源 的 访 问 超 出 进 程 的 范 畴， 而 且 使 用 临 界 区 的 方 式 效 率 比 较 高。

----同 步 访 问 类 用 于 获 得 对 这 些 控 制 资 源 的 访 问。CMultiLock 和 CSingleLock 的 区 别 仅 在 于 是 需 要 控 制 访 问 多 个 还 是 单 个 资 源 对 象。

----5 同 步 类 的 使 用 方 法

----解 决 同 步 问 题 的 一 个 简 单 的 方 法 就 是 将 同 步 类 融 入 共 享 类 当 中， 通 常 我 们 把 这 样 的 共 享 类 称 为 线 程 安 全 类。 下 面 举 例 来 说 明 这 些 同 步 类 的 使 用 方 法。 比 如， 一 个 用 以 维 护 一 个 帐 户 的 连 接 列 表 的 应 用 程 序。 该 应 用 程 序 允 许3 个 帐 户 在 不 同 的 窗 口 中 检 测， 但 一 次 只 能 更 新 一 个 帐 户。 当 一 个 帐 户 更 新 之 后， 需 要 将 更 新 的 数 据 通 过 网 络 传 给 一 个 数 据 文 档。

----该 例 中 将 使 用3 种 同 步 类。 由 于 允 许 一 次 检 测3 个 帐 户， 使 用CSemaphore 来 限 制 对3 个 视 窗 对 象 的 访 问。 当 更 新 一 个 帐 目 时， 应 用 程 序 使 用CCriticalSection 来 保 证 一 次 只 有 一 个 帐 目 更 新。 在 更 新 成 功 之 后， 发CEvent 信 号， 该 信 号 释 放 一 个 等 待 接 收 信 号 事 件 的 线 程。 该 线 程 将 新 数 据 传 给 数 据 文 档。

----要 设 计 一 个 线 程 安 全 类， 首 先 根 据 具 体 情 况 在 类 中 加 入 同 步 类 做 为 数 据 成 员。 在 例 子 当 中， 可 以 将 一 个CSemaphore 类 的 数 据 成 员 加 入 视 窗 类 中， 一 个CCriticalSection 类 数 据 成 员 加 入 连 接 列 表 类， 而 一 个CEvent 数 据 成 员 加 入 数 据 存 储 类 中。

----然 后， 在 使 用 共 享 资 源 的 函 数 当 中， 将 同 步 类 与 同 步 访 问 类 的 一 个 锁 对 象 联 系 起 来。 即， 在 访 问 控 制 资 源 的 成 员 函 数 中 应 该 创 建 一 个CSingleLock 或 CMultiLock 的 对 象 并 调 用 该 对 象 的Lock 函 数。 当 访 问 结 束 之 后， 调 用UnLock 函 数， 释 放 资 源。

----用 这 种 方 式 来 设 计 线 程 安 全 类 比 较 容 易。 在 保 证 线 程 安 全 的 同 时， 省 去 了 维 护 同 步 代 码 的 麻 烦， 这 也 正 是OOP 的 思 想。 但 是 使 用 线 程 安 全 类 方 法 编 程 比 不 考 虑 线 程 安 全 要 复 杂， 尤 其 体 现 在 程 序 调 试 过 程 中。 而 且 线 程 安 全 编 程 还 会 损 失 一 部 分 效 率， 比 如 在 单CPU 计 算 机 中 多 个 线 程 之 间 的 切 换 会 占 用 一 部 分 资 源。

三 编 程 实 例

----下 面 以VC++5.0 中 一 个 简 单 的 基 于 对 话 框 的MFC 例 程 来 说 明 实 现 多 线 程 任 务 调 度 与 处 理 的 方 法， 下 面 加 以 详 细 解 释。

----在 该 例 程 当 中 定 义 两 个 用 户 界 面 线 程， 一 个 显 示 线 程(CDisplayThread) 和 一 个 计 数 线 程(CCounterThread)。 这 两 个 线 程 同 时 操 作 一 个 字 符 串 变 量m_strNumber， 其 中 显 示 线 程 将 该 字 符 串 在 一 个 列 表 框 中 显 示， 而 计 数 线 程 则 将 该 字 符 串 中 的 整 数 加1。 在 例 程 中， 可 以 分 别 调 整 进 程、 计 数 线 程 和 显 示 线 程 的 优 先 级。 例 程 中 的 同 步 机 制 使 用CMutex 和CSingleLock 来 保 证 两 个 线 程 不 能 同 时 访 问 该 字 符 串。 同 步 机 制 执 行 与 否 将 明 显 影 响 程 序 的 执 行 结 果。 在 该 例 程 中 允 许 将 将 把 两 个 线 程 暂 时 挂 起， 以 查 看 运 行 结 果。 例 程 中 还 允 许 查 看 计 数 线 程 的 运 行。 该 例 程 中 所 处 理 的 问 题 也 是 多 线 程 编 程 中 非 常 具 有 典 型 意 义 的 问 题。

----在 该 程 序 执 行 时 主 要 有 三 个 用 于 调 整 优 先 级 的 组 合 框， 三 个 分 别 用 于 选 择 同 步 机 制、 显 示 计 数 线 程 运 行 和 挂 起 线 程 的 复 选 框 以 及 一 个 用 于 显 示 运 行 结 果 的 列 表 框。

----在 本 程 序 中 使 用 了 两 个 线 程 类CCounterThread 和CDisplayThread， 这 两 个 线 程 类 共 同 操 作 定 义 在CMutexesDlg 中 的 字 符 串 对 象m_strNumber。 本 程 序 对 同 步 类CMutex 的 使 用 方 法 就 是 按 照 本 文 所 讲 述 的 融 入 的 方 法 来 实 现 的。 同 步 访 问 类CSingleLock 的 锁 对 象 则 在 各 线 程 的 具 体 实 现 中 定 义。

----下 面 介 绍 该 例 程 的 具 体 实 现：

1.        利 用AppWizard生 成 一 个 名 为Mutexes基 于 对 话 框 的 应 用 程 序 框 架。

2.        利 用 对 话 框 编 辑 器 在 对 话 框 中 填 加 以 下 内 容： 三 个 组 合 框， 三 个 复 选 框 和 一 个 列 表 框。三 个 组 合 框 分 别 允 许 改 变 进 程 优 先 级 和 两 个 线 程 优 先 级， 其ID分 别 设 置为：IDC_PRIORITYCLASS、IDC_DSPYTHRDPRIORITY和IDC_CNTRTHRDPRIORITY。 三 个 复 选 框 分 别 对 应 着同 步 机 制 选 项、 显 示 计 数 线 程 执 行 选 项 和 暂 停 选 项， 其ID分 别 设 置为IDC_SYNCHRONIZE、IDC_SHOWCNTRTHRD和IDC_PAUSE。 列 表 框 用 于 显 示 线 程 显 示 程 序 中 两 个 线程 的 共 同 操 作 对 象m_strNumber， 其ID设 置 为IDC_DATABOX。

3.        创 建 类CWinThread的 派 生 类CExampleThread。 该 类 将 作 为 本 程 序 中 使 用 的 两 个 线 程类：CCounterThread和CDisplayThread的 父 类。 这 样 做 的 目 的 仅 是 为 了 共 享 两 个 线 程 类 的 共 用 变 量和 函 数。

----在CExampleThread 的 头 文 件 中 填 加 如 下 变 量：

CMutexesDlg * m_pOwner;//指向类CMutexesDlg指针

BOOL m_bDone;//用以控制线程执行

及函数：

void SetOwner(CMutexesDlg* pOwner)

{ m_pOwner=pOwner; };//取类CMutexesDlg的指针

然后在构造函数当中对成员变量进行初始化：

m_bDone=FALSE;//初始化允许线程运行

m_pOwner=NULL;//将该指针置为空

m_bAutoDelete=FALSE;//要求手动删除线程对象

4.        创 建 两 个 线 程 类CCounterThread和CdisplayThread。 这 两 个 线 程 类 是CExampleThread的 派 生类。 分 别 重 载 两 个 线 程 函 数 中 的::Run()函 数， 实 现 各 线 程 的 任 务。 在 这 两 个 类 当 中 分 别 加 入 同步 访 问 类 的 锁 对 象sLock， 这 里 将 根 据 同 步 机 制 的 复 选 与 否 来 确 定 是 否 控 制 对 共 享 资 源 的 访问。 不 要 忘 记 需 要 加 入 头 文 件#include "afxmt.h"。

----计 数 线 程::Run() 函 数 的 重 载 代 码 为：

int CCounterThread::Run()

{

BOOL fSyncChecked;//同步机制复选检测

unsigned int nNumber;//存储字符串中整数

if (m_pOwner == NULL)

return -1;

//将同步对象同锁对象联系起来

CSingleLock sLock(&(m_pOwner- >m_mutex));

while (!m_bDone)//控制线程运行，为终止线程服务

{

//取同步机制复选状态

fSyncChecked = m_pOwner- >

IsDlgButtonChecked(IDC_SYNCHRONIZE);

//确定是否使用同步机制

if (fSyncChecked)

sLock.Lock();

//读取整数

_stscanf((LPCTSTR) m_pOwner- >m_strNumber,

_T("%d"), &nNumber);

nNumber++;//加1

m_pOwner- >m_strNumber.Empty();//字符串置空

while (nNumber != 0) //更新字符串

{

m_pOwner- >m_strNumber +=

(TCHAR) ('0'+nNumber%10);

nNumber /= 10;

}

//调整字符串顺序

m_pOwner- >m_strNumber.MakeReverse();

//如果复选同步机制，释放资源

if (fSyncChecked)

sLock.Unlock();

//确定复选显示计数线程

if (m_pOwner- >IsDlgButtonChecked(IDC_SHOWCNTRTHRD))

m_pOwner- >AddToListBox(_T("Counter: Add 1"));

}//结束while

m_pOwner- >PostMessage(WM_CLOSE, 0, 0L);

return 0;

}

显示线程的::Run()函数重载代码为：

int CDisplayThread::Run()

{

BOOL fSyncChecked;

CString strBuffer;

ASSERT(m_pOwner != NULL);

if (m_pOwner == NULL)

return -1;

CSingleLock sLock(&(m_pOwner- >m_mutex));

while (!m_bDone)

{

fSyncChecked = m_pOwner- >

IsDlgButtonChecked(IDC_SYNCHRONIZE);

if (fSyncChecked)

sLock.Lock();

//构建要显示的字符串

strBuffer = _T("Display: ");

strBuffer += m_pOwner- >m_strNumber;

if (fSyncChecked)

sLock.Unlock();

//将字符串加入到列表框中

m_pOwner- >AddToListBox(strBuffer);

}//结束while

m_pOwner- >PostMessage(WM_CLOSE, 0, 0L);

return 0;

}

3在CMutexesDlg的头文件中加入如下成员变量：

CString m_strNumber;//线程所要操作的资源对象

CMutex m_mutex;//用于同步机制的互斥量

CCounterThread* m_pCounterThread;//指向计数线程的指针

CDisplayThread* m_pDisplayThread;//指向显示线程的指针

首先在对话框的初始化函数中加入如下代码对对话框进行初始化：

BOOL CMutexesDlg::OnInitDialog()

{

……

//初始化进程优先级组合框并置缺省为 NORMAL

CComboBox* pBox;

pBox = (CComboBox*) GetDlgItem(IDC_PRIORITYCLASS);

ASSERT(pBox != NULL);

if (pBox != NULL){

pBox- >AddString(_T("Idle"));

pBox- >AddString(_T("Normal"));

pBox- >AddString(_T("High"));

pBox- >AddString(_T("Realtime"));

pBox- >SetCurSel(1);

}

//初始化显示线程优先级组合框并置缺省为 NORMAL

pBox = (CComboBox*) GetDlgItem(IDC_DSPYTHRDPRIORITY);

ASSERT(pBox != NULL);

if (pBox != NULL){

pBox- >AddString(_T("Idle"));

pBox- >AddString(_T("Lowest"));

pBox- >AddString(_T("Below normal"));

pBox- >AddString(_T("Normal"));

pBox- >AddString(_T("Above normal"));

pBox- >AddString(_T("Highest"));

pBox- >AddString(_T("Timecritical"));

pBox- >SetCurSel(3);

}

//初始化计数线程优先级组合框并置缺省为 NORMAL

pBox = (CComboBox*) GetDlgItem(IDC_CNTRTHRDPRIORITY);

ASSERT(pBox != NULL);

if (pBox != NULL){

pBox- >AddString(_T("Idle"));

pBox- >AddString(_T("Lowest"));

pBox- >AddString(_T("Below normal"));

pBox- >AddString(_T("Normal"));

pBox- >AddString(_T("Above normal"));

pBox- >AddString(_T("Highest"));

pBox- >AddString(_T("Timecritical"));

pBox- >SetCurSel(3);

}

//初始化线程挂起复选框为挂起状态

CButton* pCheck = (CButton*) GetDlgItem(IDC_PAUSE);

pCheck- >SetCheck(1);

//初始化线程

m_pDisplayThread = (CDisplayThread*)

AfxBeginThread(RUNTIME_CLASS(CDisplayThread),

THREAD_PRIORITY_NORMAL,

0,

CREATE_SUSPENDED);

m_pDisplayThread- >SetOwner(this);

m_pCounterThread = (CCounterThread*)

AfxBeginThread(RUNTIME_CLASS(CCounterThread),

THREAD_PRIORITY_NORMAL,

0,

CREATE_SUSPENDED);

m_pCounterThread- >SetOwner(this);

……

}

然后填加成员函数：

void AddToListBox(LPCTSTR szBuffer);//用于填加列表框显示

该函数的实现代码为：

void CMutexesDlg::AddToListBox(LPCTSTR szBuffer)

{

CListBox* pBox = (CListBox*) GetDlgItem(IDC_DATABOX);

ASSERT(pBox != NULL);

if (pBox != NULL){

int x = pBox- >AddString(szBuffer);

pBox- >SetCurSel(x);

if (pBox- >GetCount()  > 100)

pBox- >DeleteString(0);

}

}

----然 后 利 用ClassWizard 填 加 用 于 调 整 进 程 优 先 级、 两 个 线 程 优 先 级 以 及 用 于 复 选 线 程 挂 起 的 函 数。

----调 整 进 程 优 先 级 的 代 码 为：

void CMutexesDlg::OnSelchangePriorityclass()

{

DWORD dw;

//取焦点选项

CComboBox* pBox = (CComboBox*)

GetDlgItem(IDC_PRIORITYCLASS);

int nCurSel = pBox- >GetCurSel();

switch (nCurSel)

{

case 0:

dw = IDLE_PRIORITY_CLASS;break;

case 1:

default:

dw = NORMAL_PRIORITY_CLASS;break;

case 2:

dw = HIGH_PRIORITY_CLASS;break;

case 3:

dw = REALTIME_PRIORITY_CLASS;break;

}

SetPriorityClass(GetCurrentProcess(), dw);//调整优先级

}

----由 于 调 整 两 个 线 程 优 先 级 的 代 码 基 本 相 似， 单 独 设 置 一 个 函 数 根 据 不 同 的ID 来 调 整 线 程 优 先 级。 该 函 数 代 码 为：

void CMutexesDlg::OnPriorityChange(UINT nID)

{

ASSERT(nID == IDC_CNTRTHRDPRIORITY ||

nID == IDC_DSPYTHRDPRIORITY);

DWORD dw;

//取对应该ID的焦点选项

CComboBox* pBox = (CComboBox*) GetDlgItem(nID);

int nCurSel = pBox- >GetCurSel();

switch (nCurSel)

{

case 0:

dw = (DWORD)THREAD_PRIORITY_IDLE;break;

case 1:

dw = (DWORD)THREAD_PRIORITY_LOWEST;break;

case 2:

dw = (DWORD)THREAD_PRIORITY_BELOW_NORMAL;break;

case 3:

default:

dw = (DWORD)THREAD_PRIORITY_NORMAL;break;

case 4:

dw = (DWORD)THREAD_PRIORITY_ABOVE_NORMAL;break;

case 5:

dw = (DWORD)THREAD_PRIORITY_HIGHEST;break;

case 6:

dw = (DWORD)THREAD_PRIORITY_TIME_CRITICAL;break;

}

if (nID == IDC_CNTRTHRDPRIORITY)

m_pCounterThread- >SetThreadPriority(dw);

//调整计数线程优先级

else

m_pDisplayThread- >SetThreadPriority(dw);

//调整显示线程优先级

}

这样线程优先级的调整只需要根据不同的ID来调用该函数：

void CMutexesDlg::OnSelchangeDspythrdpriority()

{ OnPriorityChange(IDC_DSPYTHRDPRIORITY);}

void CMutexesDlg::OnSelchangeCntrthrdpriority()

{ OnPriorityChange(IDC_CNTRTHRDPRIORITY);}

复选线程挂起的实现代码如下：

void CMutexesDlg::OnPause()

{

//取挂起复选框状态

CButton* pCheck = (CButton*)GetDlgItem(IDC_PAUSE);

BOOL bPaused = ((pCheck- >GetState() & 0x003) != 0);

if (bPaused)     {

m_pCounterThread- >SuspendThread();

m_pDisplayThread- >SuspendThread();

}//挂起线程

else     {

m_pCounterThread- >ResumeThread();

m_pDisplayThread- >ResumeThread();

}//恢复线程运行

}

----程 序 在::OnClose() 中 实 现 了 线 程 的 终 止。 在 本 例 程 当 中 对 线 程 的 终 止 稍 微 复 杂 些。 需 要 注 意 的 是 成 员 变 量m_bDone 的 作 用， 在 线 程 的 运 行 当 中 循 环 检 测 该 变 量 的 状 态， 最 终 引 起 线 程 的 退 出。 这 样 线 程 的 终 止 是 因 为 函 数 的 退 出 而 自 然 终 止， 而 非 采 用 强 行 终 止 的 方 法， 这 样 有 利 于 系 统 的 安 全。 该 程 序 中 使 用 了PostMessage 函 数， 该 函 数 发 送 消 息 后 立 即 返 回， 这 样 可 以 避 免 阻 塞。 其 实 现 的 代 码 为：

void CMutexesDlg::OnClose()

{

int nCount = 0;

DWORD dwStatus;

//取挂起复选框状态

CButton* pCheck = (CButton*) GetDlgItem(IDC_PAUSE);

BOOL bPaused = ((pCheck- >GetState() & 0x003) != 0);

if (bPaused == TRUE){

pCheck- >SetCheck(0);//复选取消

m_pCounterThread- >ResumeThread();

//恢复线程运行

m_pDisplayThread- >ResumeThread();

}

if (m_pCounterThread != NULL){

VERIFY(::GetExitCodeThread(m_pCounterThread- >

m_hThread, &dwStatus));//取计数线程结束码

if (dwStatus == STILL_ACTIVE){

nCount++;

m_pCounterThread- >m_bDone = TRUE;

}//如果仍为运行状态，则终止

else{

delete m_pCounterThread;

m_pCounterThread = NULL;

}//如果已经终止，则删除该线程对象

}

if (m_pDisplayThread != NULL){

VERIFY(::GetExitCodeThread(m_pDisplayThread- >

m_hThread, &dwStatus));//取显示线程结束码

if (dwStatus == STILL_ACTIVE){

nCount++;

m_pDisplayThread- >m_bDone = TRUE;

}//如果仍为运行状态，则终止

else{

delete m_pDisplayThread;

m_pDisplayThread = NULL;

}//如果已经终止，则删除该线程对象

}

if (nCount == 0)//两个线程均终止，则关闭程序

CDialog::OnClose();

else //否则发送WM_CLOSE消息

PostMessage(WM_CLOSE, 0, 0);

}

----在 例 程 具 体 实 现 中 用 到 了 许 多 函 数， 在 这 里 不 一 一 赘 述， 关 于 函 数 的 具 体 意 义 和 用 法， 可 以 查 阅 联 机 帮 助。

Visual C++ 5.0中的多线程编程技术

　　潘爱民

　　一、引言

　　Windows系统平台经历了从16位到32位的转变后，系统运行方式和任务管理方式有了很大的变化，在Windows 95和Windows NT中，每个Win32程序在独立的进程空间上运行，32位地址空间使我们从16位段式结构的64K段限制中摆脱出来，逻辑上达到了4G的线性地址空间。这样，我们在设计程序时就不再需要考虑编译的段模式，同时还提高了大程序的运行效率。独立进程空间的另一个更大的优越性是大大提高了系统的稳定性，一个应用程序的异常错误不会影响其它的应用程序，这对于现在的桌面环境尤为重要。

　　在Windows的一个进程内，包含一个或多个线程。线程是指进程的一条执行路径，它包含独立的堆栈和CPU寄存器状态，每个线程共享所有的进程资源，包括打开的文件、信号标识及动态分配的内存等等。一个进程内的所有线程使用同一个32位地址空间，而这些线程的执行由系统调度程序控制，调度程序决定哪个线程可执行以及什么时候执行线程。线程有优先级别，优先权较低的线程必须等到优先权较高的线程执行完任务后再执行。在多处理器的机器上，调度程序可将多个线程放到不同的处理器上去运行，这样就可使处理器的任务平衡，也提高了系统的运行效率。

　　32位Windows环境下的Win32 API提供了多线程应用程序开发所需要的接口函数，但Win16和Win32对多线程应用并不支持，利用Visual C++ 5.0中提供的标准C库也可以开发多线程应用程序，而相应的MFC4.21类库则封装了多线程编程的类，因而用户在开发时可根据应用程序的需要和特点选择相应的工具。

　　如果用户的应用程序需要有多个任务同时进行相应的处理，则使用多线程是较理想的选择。例如，就网络文件服务功能的应用程序而言，若采用单线程编程方法，则需要循环检查网络的连接、磁盘驱动器的状况，并在适当的时候显示这些数据，必须等到一遍查询后才能刷新数据的显示。对使用者来说，延迟可能很长。而在应用多线程的情况下可将这些任务分给多个线程，一个线程负责检查网络，另一个线程管理磁盘驱动器，还有一个线程负责显示数据，三个线程结合起来共同完成文件服务，使用者也可以及时看到网络的变化。多线程应用范围很广，尤其是在目前的桌面平台上，系统的许多功能如网络(Internet)、打印、字处理、图形图像、动画和文件管理都在一个系统下运行，更需要我们的应用程序能够同时处理多个事件，而这些正是多线程可以实现的。本文讲述了利用Visual C++ 5.0进行多线程开发的编程技术。

　　二、基于Visual C++的多线程编程

　　Visual C++ 5.0提供了Windows应用程序的集成开发环境Developer Studio。在这个环境里，用户既可以编写C风格的32位Win32应用程序，也可以利用MFC类库编写C++风格的应用程序，二者各有其优点：基于Win32的应用程序执行代码小巧，运行效率高，但要求程序员编写的代码较多，且需要管理所有系统提供给程序的资源；而基于MFC类库的应用程序可以快速建立起应用程序，类库为程序员提供了大量的封装类，而且Developer Studio为程序员提供了一些工具来管理用户源程序，其缺点是类库代码很庞大，应用程序的执行代码离不开这些代码。由于使用类库所带来的快速、简捷和功能强大等优越性，因此，除非有特殊的需要，否则Visual C++提倡使用MFC类库进行应用程序开发。

　　多线程的编程在Win32方式下和MFC类库支持下的原理是一致的，进程的主线程在任何需要的时候都可以创建新的线程。当线程执行完任务后，自动中止线程；当进程结束后，所有的线程都中止。所有活动的线程共享进程的资源。因此，在编程时需要考虑在多个线程访问同一资源时产生冲突的问题：当一个线程正在访问一个进程对象时，另一个线程要改变该对象，这时可能会产生错误的结果。所以，程序员编程时要解决这种冲突。

　　下面给大家介绍一下在Win32 基础上进行多线程编程的过程。

　　1.用Win32函数创建和中止线程

　　Win32函数库中提供了多线程控制的操作函数，包括创建线程、中止线程、建立互斥区等。首先，在应用程序的主线程或者其它活动线程的适当地方创建新的线程。创建线程的函数如下：

　　HANDLE CreateThread(LPSECURITY_ATTRIBUTES lpThreadAttributes, DWORD dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId );

　　其中，参数lpThreadAttributes 指定了线程的安全属性，在Windows 95中被忽略；dwStackSize 指定了线程的堆栈深度；lpStartAddress 指定了线程的起始地址，一般情况为下面的原型函数：DWORD WINAPI ThreadFunc( LPVOID );lpParameter指定了线程执行时传送给线程的32位参数，即上面函数的参数；dwCreationFlags指定了线程创建的特性； lpThreadId 指向一个DWORD变量，可返回线程ID值。

　　如果创建成功则返回线程的句柄，否则返回NULL。

　　创建了新的线程后，则该线程就开始启动执行了。如果在dwCreationFlags中用了CREATE_SUSPENDED特性，那么线程并不马上执行，而是先挂起，等到调用ResumeThread后才开始启动线程，在这个过程中可以调用函数：

　　BOOL SetThreadPriority( HANDLE hThread, int nPriority);

　　来设置线程的优先权。

　　当线程的函数返回后，线程自动中止。如果在线程的执行过程中中止的话，则可调用函数：

　　VOID ExitThread( DWORD dwExitCode);

　　如果在线程的外面中止线程的话，则可调用下面的函数：

　　BOOL TerminateThread( HANDLE hThread, DWORD dwExitCode );

　　但应注意：该函数可能会引起系统不稳定，而且线程所占用的资源也不释放。因此，一般情况下，建议不要使用该函数。

　　如果要中止的线程是进程内的最后一个线程，则在线程被中止后相应的进程也应中止。

　　2.用Win32函数控制线程对共享资源的访问

　　在线程体内，如果该线程完全独立，与其它的线程没有数据存取等资源操作上的冲突，则可按照通常单线程的方法进行编程。但是，在多线程处理时情况常常不是这样，线程之间经常要同时访问一些资源。例如，一个线程负责公式计算，另一个线程负责结果的显示，两个线程都要访问同一个结果变量。这时如果不进行冲突控制的话，则很可能显示的是不正确的结果。

　　对共享资源进行访问引起冲突是不可避免的，但我们可用以下办法来进行操作控制：

　　(1) 通过设置线程的互斥体对象，在可能冲突的地方进行同步控制。

　　首先，建立互斥体对象，得到句柄：

　　HANDLE CreateMutex( );

　　然后，在线程可能冲突区域的开始（即访问共享资源之前），调用WaitForSingleObject将句柄传给函数，请求占用互斥体对象：

　　dwWaitResult = WaitForSingleObject(hMutex, 5000L);

　　共享资源访问完后，释放对互斥体对象的占用：

　　ReleaseMutex(hMutex);

　　互斥体对象在同一时刻只能被一个线程占用。当互斥体对象被一个线程占用时，若有另一线程想占用它，则必须等到前一线程释放后才能成功。

　　(2) 设置信号：在操作共享资源前，打开信号；完成操作后，关闭信号。这类似于互斥体对象的处理。

　　首先，创建信号对象：

　　HANDLE CreateSemaphore( );

　　或者打开一个信号对象：

　　HANDLE OpenSemaphore( );

　　然后，在线程的访问共享资源之前调用WaitForSingleObject。

　　共享资源访问完后，释放对信号对象的占用：

　　ReleaseSemaphore();

　　信号对象允许同时对多个线程共享资源的访问，在创建对象时指定最大可同时访问的线程数。当一个线程申请访问成功后，信号对象中的计数器减一；调用ReleaseSemaphore函数后，信号对象中的计数器加一。其中，计数器值大于等于0，小于等于创建时指定的最大值。利用信号对象，我们不仅可以控制共享资源的访问，还可以在应用的初始化时候使用。假定一个应用在创建一个信号对象时，将其计数器的初始值设为0，这样就阻塞了其它线程，保护了资源。待初始化完成后，调用ReleaseSemaphore函数将其计数器增加至最大值，进行正常的存取访问。

　　(3) 利用事件对象的状态，进行线程对共享资源的访问。

　　用ResetEvent函数设置事件对象状态为不允许线程通过；用SetEvent函数设置事件对象状态为可以允许线程通过。

　　事件分为手工释放和自动释放。如果是手工释放，则按照上述两函数处理事件的状态；如果是自动释放，则在一个线程结束后，自动清除事件状态，允许其它线程通过。

　　(4) 设置排斥区。在排斥区中异步执行时，它只能在同一进程的线程之间共享资源处理。虽然此时上面介绍的三种方法均可使用，但是，使用排斥区的方法则使同步管理的效率更高；

　　先定义一个CRITICAL_SECTION结构的排斥区对象，在进程使用之前先对对象进行初始化，调用如下函数：

　　VOID InitializeCriticalSection( LPCRITICAL_SECTION );

　　当一个线程使用排斥区时，调用函数：

　　EnterCriticalSection或者TryEnterCriticalSection

　　当要求占用、退出排斥区时，调用函数：

　　LeaveCriticalSection

　　释放对排斥区对象的占用，供其它线程使用。

　　互斥体对象、信号对象和事件对象也可以用于进程间的线程同步操作。在用Win32函数创建了对象时，我们可以指定对象的名字，还可以设置同步对象在子进程的继承性。创建返回的是HANDLE句柄，我们可以用函数DuplicateHandle来复制对象句柄，这样每个进程都可以拥有同一对象的句柄，实现进程之间的线程同步操作。另外，在同一进程内，我们可以用OpenMutex、OpenSemaphore和OpenEvent来获得指定名字的同步对象的句柄。

　　排斥区异步执行的线程同步方法只能用于同一进程的线程之间共享资源处理，但是这种方法的使用效率较高，而且编程也相对简单一些。

　　在Visual C++中，除了利用Win32函数进行多线程同步控制外，如果我们用到了MFC类库，则可利用已经封装成C++类结构的同步对象，使我们的编程更加简捷。

　　三、基于MFC的多线程编程

　　在Visual C++ 5.0附带的MFC 4.21类库中，也提供了多线程编程的支持，基本原理与上面所讲的基于Win32函数的设计一致，但由于MFC对同步对象作了封装，因此对用户编程实现来说更加方便，避免了对象句柄管理上的繁琐工作。更重要的是，在多个窗口线程情况下，MFC中直接提供了用户接口线程的设计。

　　在MFC中，线程分为两种：用户接口线程和辅助线程。用户接口线程常用于接收用户的输入，处理相应的事件和消息。在用户接口线程中，包含一个消息处理循环，其中CWinApp就是一个典型的例子，它从CWinThread派生出来，负责处理用户输入产生的事件和消息。辅助线程常用于任务处理（比如计算）不要求用户输入，对用户而言，它在后台运行。Win32 API并不区分这两种线程的类型，它只是获取线程的起始地址，然后开始执行线程。而MFC则针对不同的用户需要作了分类。如果我们需要编写多个有用户接口的线程的应用程序，则利用Win32 API要写很多的框架代码来完成每个线程的消息事件的处理，而用MFC则可以充分发挥MFC中类的强大功能，还可以使用ClassWizard来帮助管理类的消息映射和成员变量等，我们就可以把精力集中到应用程序的相关代码编写上。

　　辅助线程编程较为简单，设计的思路与上节所讲的基本一致：一个基本函数代表了一个线程，创建并启动线程后，则线程进入运行状态；如果线程用到共享资源，则需要进行资源同步处理。共享资源的同步处理在两种线程模式下完全一致。

　　我们知道：基于MFC的应用程序有一个应用对象，它是CWinApp派生类的对象，该对象代表了应用进程的主线程。当线程执行完(通常是接收到WM_QUIT消息)并退出线程时，由于进程中没有其它线程的存在，故进程也自动结束。类CWinApp从CWinThread派生出来，CWinThread是用户接口线程的基本类。我们在编写用户接口线程时，需要从CWinThread派生我们自己的线程类，ClassWizard可以帮助我们完成这个工作。

　　下面列出编写用户接口线程的基本步骤。

　　1.用ClassWizard派生一个新的类，设置基类为CWinThread

　　注意：类的DECLARE_DYNCREATE 和 IMPLEMENT_DYNCREATE宏是必需的，因为创建线程时需要动态创建类的对象。根据需要可将初始化和结束代码分别放到类的InitInstance和ExitInstance函数中。如果需要创建窗口，则可在InitInstance函数中完成。

　　2.创建线程并启动线程

　　可以用两种方法来创建用户接口线程。

　　（1）MFC提供了两个版本的AfxBeginThread函数，其中一个用于创建用户接口线程，函数原型如下：

　　CWinThread* AfxBeginThread(CRuntimeClass* pThreadClass, int nPriority, UINT nStackSize , DWORD dwCreateFlags, LPSECURITY_ATTRIBUTES lpSecurityAttrs );

　　其中，参数pThreadClass指定线程的运行类，函数返回线程对象。

　　在创建线程时，可以指定线程先挂起，将参数dwCreateFlags设置为CREATE_SUSPENDED。然后，做一些初试工作，如对变量赋值等。最后，再调用线程类的ResumeThread函数启动线程。

　　函数AfxBeginThread的另一个版本指定一个线程函数并设置相应的参数，其它设置及用法与上述函数基本相同。

　　（2）我们也可以不用AfxBeginThread创建线程，而是分两步完成：首先，调用线程类的构造函数创建一个线程对象；其次，调用CWinThread::CreateThread函数来创建该线程。

　　注意：在这种情况下，在线程类中需要有公有的构造函数以创建其相应的C++对象。

　　线程建立并启动后，则线程在线程函数执行过程中一直有效。如果是线程对象，则在对象被删除之前，先结束线程。CWinThread已经为我们完成了线程结束的工作。

　　3. 同步对象的使用

　　不管是辅助线程还是用户接口线程，在存取共享资源时，都需要保护共享资源，以免引起冲突，造成错误。处理方法类似于Win32 API函数的使用，但MFC为我们提供了几个同步对象C++类，即CSyncObject、CMutex、CSemaphore、CEvent、CCriticalSection。这里，CSyncObject为其它四个类的基类，后四个类分别对应前面所讲的四个Win32 API同步对象。

　　通常，我们在C++对象的成员函数中使用共享资源，或者把共享资源封装在C++类的内部。我们可将线程同步操作封装在对象类的实现函数当中，这样在应用中的线程使用C++对象时，就可以像一般对象一样使用它，简化了使用部分代码的编写，这正是面向对象编程的思想。这样编写的类被称作“线程安全类”。在设计线程安全类时，首先应根据具体情况在类中加入一个同步对象类数据成员。然后，在类的成员函数中，凡是所有修改公共数据或者读取公共数据的地方均要加入相应的同步调用。一般的处理步骤是：创建一个CSingleLock或者CMultiLock对象，然后调用其Lock函数。当对象结束时，自动在析构函数中调用Unlock函数，当然也可以在任何希望的地方调用Unlock函数。

　　如果不是在特定的C++对象中使用共享资源，而是在特定的函数中使用共享资源（这样的函数称为“线程安全函数”），那么还是按照前面介绍的办法去做：先建立同步对象，然后调用等待函数，直到可以访问资源，最后释放对同步对象的控制。

　　下面我们讨论四个同步对象分别适用的场合：

　　（1）如果某个线程必须等待某些事件发生后才能存取相应资源，则用CEvent；

　　（2）如果一个应用同时可以有多个线程存取相应资源，则用CSemaphore；

　　（3）如果有多个应用(多个进程)同时存取相应资源，则用CMutex，否则用CCriticalSection。

　　使用线程安全类或者线程安全函数进行编程，比不考虑线程安全的编程要复杂，尤其在进行调试时情况更为复杂，我们必须灵活使用Visual C++提供的调试工具，以保证共享资源的安全存取。线程安全编程的另一缺点是运行效率相对要低些，即使在单个线程运行的情况下也会损失一些效率。所以，我们在实际工作中应具体问题具体分析，以选择合适的编程方法。

　　4. 多线程编程例程分析

　　上面讲述了在Visual C++ 5.0中进行多线程编程的技术要点，为了充分说明这种技术，我们来分析一下Visual C++提供的有关多线程的例程，看看一些多线程元素的典型用法。读者可运行这些例程，以获得多线程运行的直观效果。

　　（1）MtRecalc

　　例程MtRecalc的功能是在一个窗口中完成简单的加法运算，用户可输入加数和被加数，例程完成两数相加。用户可通过菜单选择单线程或用辅助线程来做加法运算。如果选择辅助线程进行加法运算，则在进行运算的过程中，用户可继续进行一些界面操作，如访问菜单、编辑数值等，甚至可以中止辅助运算线程。为了使其效果更加明显，例程在计算过程中使用了循环和延时，模拟一个复杂的计算过程。

　　在程序的CRecalcDoc类中，用到了一个线程对象和四个同步事件对象：

　　CWinThread* m_pRecalcWorkerThread;

　　HANDLE m_hEventStartRecalc;

　　HANDLE m_hEventRecalcDone;

　　HANDLE m_hEventKillRecalcThread;

　　HANDLE m_hEventRecalcThreadKilled;

　　当用户选择了菜单项Worker Thread后，多线程功能才有效。这时，或者选择菜单项Recalculate Now，或者在窗口中的编辑控制转移焦点时，都会调用函数：

　　void CRecalcDoc::UpdateInt1AndInt2(int n1, int n2, BOOL bForceRecalc);

　　在多线程的情况下，还会调用下面的CRecalcDoc::RecalcInSecondThread函数：

　　void CRecalcDoc::RecalcInSecondThread()

　　{

　　if (m_pRecalcWorkerThread == NULL)

　　{

　　m_pRecalcWorkerThread =

　　AfxBeginThread(RecalcThreadProc, &m_recalcThreadInfo);

　　}

　　m_recalcThreadInfo.m_nInt1 = m_nInt1;

　　m_recalcThreadInfo.m_nInt2 = m_nInt2;

　　POSITION pos = GetFirstViewPosition();

　　CView* pView = GetNextView(pos);

　　m_recalcThreadInfo.m_hwndNotifyRecalcDone = pView->m_hWnd;

　　m_recalcThreadInfo.m_hwndNotifyProgress = AfxGetMainWnd()->m_hWnd;

　　m_recalcThreadInfo.m_nRecalcSpeedSeconds = m_nRecalcSpeedSeconds;

　　SetEvent(m_hEventRecalcDone);

　　ResetEvent(m_hEventKillRecalcThread);

　　ResetEvent(m_hEventRecalcThreadKilled);

　　SetEvent(m_hEventStartRecalc);

　　}

　　上面加粗的语句是与多线程直接相关的代码，应用程序调用AfxBeginThread启动了线程，把m_recalcThreadInfo作为参数传给线程函数。函数中最后的四行语句设置了四个事件对象的状态，这些事件对象在文档类的构造函数中创建。下面是实际的运算线程函数：

　　UINT RecalcThreadProc(LPVOID pParam)

　　{

　　CRecalcThreadInfo* pRecalcInfo = (CRecalcThreadInfo*)pParam;

　　BOOL bRecalcCompleted;

　　while (TRUE)

　　{

　　bRecalcCompleted = FALSE;

　　if (WaitForSingleObject(pRecalcInfo->m_hEventStartRecalc, INFINITE)

　　!= WAIT_OBJECT_0)

　　break;

　　if (WaitForSingleObject(pRecalcInfo->m_hEventKillRecalcThread, 0)

　　WAIT_OBJECT_0)

　　break; // Terminate this thread by existing the proc.

　　ResetEvent(pRecalcInfo->m_hEventRecalcDone);

　　bRecalcCompleted = SlowAdd(pRecalcInfo->m_nInt1,

　　pRecalcInfo->m_nInt2,

　　pRecalcInfo->m_nSum,

　　pRecalcInfo,

　　pRecalcInfo->m_nRecalcSpeedSeconds,

　　pRecalcInfo->m_hwndNotifyProgress);

　　SetEvent(pRecalcInfo->m_hEventRecalcDone);

　　if (!bRecalcCompleted) // If interrupted by kill then...

　　break; // terminate this thread by exiting the proc.

　　::PostMessage(pRecalcInfo->m_hwndNotifyRecalcDone, WM_USER_RECALC_DONE, 0, 0);

　　}

　　if (!bRecalcCompleted)

　　SetEvent(pRecalcInfo->m_hEventRecalcThreadKilled);

　　return 0;

　　}

　　BOOL SlowAdd(int nInt1, int nInt2, int& nResult, CRecalcThreadInfo* pInfo, int nSeconds,HWND hwndNotifyProgress)

　　{

　　CWnd* pWndNotifyProgress = CWnd::FromHandle(hwndNotifyProgress);

　　BOOL bRestartCalculation = TRUE;

　　while (bRestartCalculation)

　　{

　　bRestartCalculation = FALSE;

　　for (int nCount = 1; nCount <20; nCount++)

　　{

　　if (pInfo != NULL

　　&& WaitForSingleObject(pInfo->m_hEventKillRecalcThread, 0) == WAIT_OBJECT_0)

　　{

　　if (hwndNotifyProgress != NULL)

　　{

　　pWndNotifyProgress->PostMessage( WM_USER_RECALC_IN_PROGRESS);

　　}

　　return FALSE; // Terminate this recalculation

　　}

　　if (pInfo != NULL

　　&&WaitForSingleObject(pInfo->m_hEventStartRecalc, 0) == WAIT_OBJECT_0)

　　{

　　nInt1 = pInfo->m_nInt1;

　　nInt2 = pInfo->m_nInt2;

　　bRestartCalculation = TRUE;

　　continue;

　　}

　　// update the progress indicator

　　Sleep(nSeconds * 50);

　　}

　　// update the progress indicator

　　}

　　nResult = nInt1 + nInt2;

　　return TRUE;

　　}

　　上面的代码充分显示了几个事件对象的用法。当线程刚启动时，先等待m_hEventStartRecalc的状态为允许，然后检查m_hEventKillRecalcThread事件对象的状态。注意这两个等待函数调用的第二个参数的区别：在进入计算函数之前，设置m_hEventRecalcDone事件为不允许状态；待计算结束后，将其设置为允许状态。在计算函数的处理过程中，循环检查事件m_hEventKillRecalcThread和m_hEventStartRecalc的状态，如果m_hEventKillRecalcThread事件允许，则退出线程，中止计算。

　　当计算线程在计算时，主线程可继续接受用户输入（包括菜单选择）。用户可通过菜单项中止计算线程。中止线程的处理比较简单，代码如下：

　　void CRecalcDoc::OnKillWorkerThread()

　　{

　　SetEvent(m_hEventKillRecalcThread);

　　SetEvent(m_hEventStartRecalc);

　　WaitForSingleObject(m_hEventRecalcThreadKilled, INFINITE);

　　m_pRecalcWorkerThread = NULL;

　　m_bRecalcInProgress = FALSE; // but m_bRecalcNeeded is still TRUE

　　UpdateAllViews(NULL, UPDATE_HINT_SUM);

　　}

　　通过设置m_hEventKillRecalcThread事件对象，计算线程的循环就会检测到该事件的状态，最终引起线程的退出。注意：线程的中止因函数的退出而自然中止，而没有用强行办法中止，这样可保证系统的安全性。另外，在程序的很多地方使用了PostMessage来更新计算进度的指示，使用PostMessage函数发送消息可立即返回，无需等待，这样就避免了阻塞，比较符合多线程编程的思想，建议读者使用这种消息发送方法。尤其是在多个UI线程编程时，用这种方法更合适。

　　（2）MtMDI

　　 例程MtMDI是一个MDI应用，每一个子窗口是一个用户接口线程，子窗口里有一个来回弹跳的小球，小球的运动由计时器控制，此处不加以讨论。下面，我们来看看UI线程的创建过程以及它与MDI的结合。

　　通过菜单命令New Bounce，可在主框架窗口类中响应菜单命令，函数代码如下：

　　void CMainFrame::OnBounce()

　　{

　　CBounceMDIChildWnd *pBounceMDIChildWnd = new CBounceMDIChildWnd;

　　if (!pBounceMDIChildWnd->Create( _T("Bounce"),

　　WS_CHILD | WS_VISIBLE | WS_OVERLAPPEDWINDOW, rectDefault, this))

　　return;

　　}

　　函数调用子框架窗口的创建函数，代码如下：

　　BOOL CBounceMDIChildWnd::Create(LPCTSTR szTitle, LONG style, const RECT& rect, CMDIFrameWnd* parent)

　　{

　　// Setup the shared menu

　　if (menu.m_hMenu == NULL)

　　menu.LoadMenu(IDR_BOUNCE);

　　m_hMenuShared = menu.m_hMenu;

　　if (!CMDIChildWnd::Create(NULL, szTitle, style, rect, parent))

　　return FALSE;

　　CBounceThread* pBounceThread = new CBounceThread(m_hWnd);

　　pBounceThread->CreateThread();

　　return TRUE;

　　}

　　当CBounceMDIChildWnd子窗口被删除时，Windows会同时删除CBounceWnd窗口(内嵌在线程对象pBounceThread中)，因为它是CBounceMDIChildWnd的子窗口。由于CBounceWnd运行在单独的线程中，故当CBounceWnd子窗口被删除时，CWinThread线程对象也会自动被删除。

　　上述函数生成一个新的UI线程对象pBounceThread，并调用CreateThread函数创建线程。至此，线程已被创建，但还需要做初始化工作，如下面的函数InitInstance所示：

　　int CBounceThread::InitInstance()

　　{

　　CWnd* pParent = CWnd::FromHandle(m_hwndParent);

　　CRect rect;

　　pParent->GetClientRect(&rect);

　　BOOL bReturn = m_wndBounce.Create(_T("BounceMTChildWnd"),WS_CHILD | WS_VISIBLE, rect, pParent);

　　if (bReturn)

　　m_pMainWnd = &m_wndBounce;

　　return bReturn;

　　}

　　注意：这里，将m_pMainWnd设置为新创建的CBounceWnd窗口是必需的。只有这样设置了，才能保证当CBounceWnd窗口被删除时，线程会被自动删除。

　　（3）Mutexes

　　例程Mutexes是一个对话框程序。除主线程外，还有两个线程：一个用于计数，一个用于显示。在本例中，这两个线程都是从CWinThread派生出来的，但并不用于消息循环处理，派生类重载了Run函数，用于完成其计数和显示的任务。

　　在对话框类中使用了一个内嵌的CMutex对象。对话框初始化时创建两个线程，并设置相应的参数，然后启动运行两个线程。

　　当用户设置了对话框的同步检查框标记后，两个线程的同步处理有效。在计数线程的循环中，先调用CSingleLock::Lock函数，然后进行计数修改，最后调用CSingleLock::Unlock函数。注意：这里的CSingleLock对象根据主对话框的CMutex对象产生。在显示线程的循环中，先调用CSingleLock::Lock函数，然后取到计数值，最后调用CSingleLock::Unlock函数。注意：这里的CSingleLock对象也是由主对话框的CMutex对象产生。类似这种情况:一个线程要读取数据，另一个线程要修改数据，这是我们在处理多线程问题时碰到的最典型的情况。此处采用的方法也具有典型意义。源代码可通过查看例程或通过联机帮助来获取。

　　五、结束语

　　多线程函数是Win32不同于Win16的一个重要方面，其编程技术较为新颖，在程序设计思路上不同于传统的模块结构化方法，比一般的面向对象的思路也较为复杂，尤其是对于多处理器平台的处理更为复杂。要设计出性能良好的多线程程序，不仅需要对操作系统的处理过程很清楚，还需要对具体应用有一个全面的认识，并对应用中各线程部分的关系非常清楚，对同步模块中的同步对象的具体含义应尽可能地清晰明了，以利于在程序中控制同步事件的发生，避免出现死锁或不能同步处理的现象。

　　在其它的开发语言（如Visual Basic 5.0）中也提供了对多线程的支持，但从性能和安全的角度考虑，这种多线程支持受到较多的限制。不过，就一般应用而言，用这种处理方法已经足够了。

　　目前，大多数的计算机都是单处理器(CPU)的，在这种机器上运行多线程程序，有时反而会降低系统的性能。如果两个非常活跃的线程为了抢夺对CPU的控制权，则在线程切换时会消耗很多的CPU资源，但对于大部分时间被阻塞的线程（例如等待文件I/O操作），则可用一个单独的线程来完成。这样，就可将CPU时间让出来，使程序获得更好的性能。因此，在设计多线程应用程序时，应慎重选择，并且视具体情况加以处理，使应用程序获得最佳的性能。

作者：

评价：

上站日期: 2001年09月05日

内容说明：

来源：