MFC 多线程程序设计

MFC 多线程程序设计

Multi-threaded Programming in MFC

线程（thread），是执行线程（thread of execution）的简单称呼。"Thread" 这个字的原意是「线」。

中文字里头的「线程」也有「线」的意思，所以我采用「线程」、「执行线程」这样的中文名

称。如果你曾经看过「多线」这个名词，其实就是本章所谓的「多线程」。

我曾经在第１章以三两个小节介绍Win32 环境下的进程与执行线程观念，并且以程序直接

调用CreateThread 的形式，示范了几个Win32 小例子。现在我要更进一步从操作系统

的层面谈谈执行线程的学理基础，然后带引各位看看MFC 对于「执行线程」支持了什么样

的类别。然后，实际写个MFC 多线程程序。

从操作系统层面看执行线程

书籍推荐：如果要从操作系统层面来了解执行线程，Matt Pietrek 的Windows 95 System

Programming SECRETS（Windows 95 系统程序设计大奥秘/侯俊杰译/旗标出版）无疑是

最佳知识来源。Matt 把操作系统核心模块（KERNEL32.DLL）中用来维护执行线程生存的

数据结构都挖掘出来，非常详尽。这是对执行线程的最基础认识，直达其灵魂深处。

你已经知道，CreateThread 可以产生一个执行线程，而「线程」的本体就是CreateThread 第

３个参数所指定的一个函数（一般我们称之为「执行线程函数」）。这个函数将与目前的

「执行事实」同时并行，成为另一个「执行事实」。执行线程函数的执行期，也就是该执

行线程的生命期。

操作系统如何造成这种多任务并行的现象？执行线程对于操作系统的意义到底是什么？系统

如何维护许多个执行线程？执行线程与其父亲大人（进程）的关系如何维持？CPU 只有一

个，执行线程却有好几个，如何摆平优先权与排程问题？这些疑问都可以在下面各节中获

得答案。

三个观念：模块、进程、执行线程

试着回答这个问题：进程（process）是什么？给你一分钟时间。

z z z z z...

你的回答可能是：『一个可执行档执行起来，就是一个进程』。唔，也不能算错。但能

不能够有更具体的答案？再问你一个问题：模块（module）是什么？可能你的回答还是：

『一个可执行档执行起来，就是一个模块』。这也不能够算错。但是你明明知道，模块

不等于进程。KERNEL32 DLL 是一个模块，但不是一个进程；Scribble EXE 是一个模块，

也是一个进程。

我们需要更具体的资料，更精准的答案。

如果我们能够知道操作系统如何看待模块和进程，就能够给出具体的答案了。一段可执

行的程序（包括EXE 和DLL），其程序代码、资料、资源被加载到内存中，由系统建

置一个数据结构来管理它，就是一个模块。这里所说的数据结构，名为Module Database

（MDB），其实就是PE 格式中的PE 表头，你可以从WINNT.H 档中找到一个

IMAGE_NT_HEADER 结构，就是它。

好，解释了模块，那么进程是什么？这就比较抽象一点了。这样说，进程就是一大堆拥

有权（ownership）的集合。进程拥有地址空间（由memory context 决定）、动态配置而

来的内存、文件、执行线程、一系列的模块。操作系统使用一个所谓的Process Database

（PDB）数据结构，来记录（管理）它所拥有的一切。

执行线程呢？执行线程是什么？进程主要表达「拥有权」的观念，执行线程则主要表达模块中

的程序代码的「执行事实」。系统也是以一个特定的数据结构（Thread Database，TDB）记

录执行线程的所有相关资料，包括执行线程区域储存空间（Thread Local Storage，TLS）、讯

息队列、handle 表格、地址空间（Memory Context）等等等。

最初，进程是以一个执行线程（称为主执行线程，primary thread）做为开始。如果需要，行程可以产生更多的执行线程（利用CreateThread），让CPU 在同一时间执行不同段落的码。当然，我们都知道，在只有一颗CPU 的情况下，不可能真正有多任务的情况发生，「多个执行线程同时工作」的幻觉主要是靠排程器来完成-- 它以一个硬件定时器和一组复杂的游戏规则，在不同的执行线程之间做快速切换动作。以Windows 95 和Windows NT 而言，在非特殊的情况下，每个执行线程被CPU 照顾的时间（所谓的timeslice）是20 个milliseconds。

如果你有一部多CPU 计算机，又使用一套支持多CPU 的操作系统（如Windows NT），

那么一个CPU 就可以分配到一个执行线程，真正做到实实在在的多任务。这种操作系统特性

称为symmetric multiprocessing（SMP）。Windows 95 没有SMP 性质，所以即使在多CPU 计算机上跑，也无法发挥其应有的高效能。

图14-1 表现出一个进程（PDB）如何透过「MODREF 串行」连接到其所使用的所有模组。图14-2 表现出一个模块数据结构（MDB）的细部内容，最后的DataDirectory[16] 记录着16 个特定节区（sections）的地址，这些sections 包括程序代码、资料、资源。图

14-3 表现出一个执行线程数据结构（PDB）的细部内容。

当Windows 加载器将程序加载内存中，KERNEL32 挖出一些内存，构造出一个

PDB、一个TDB、一个以上的MDBs（视此程序使用到多少DLL 而定）。针对TDB，

操作系统又要产生出memory context（就是在操作系统书籍中提到的那些所谓page tables）、消息队列、handle 表格、环境数据结构（EDB）...。当这些系统内部数据结构

都构造完毕，指令指位器（Instruction Pointer）移到程序的进入点，才开始程序的执行。图14-1 进程（PDB ）透过「MODREF 串行」连接到其所使用的所有模块

执行线程优先权(Priority)

我想我们现在已经能够用很具体的形象去看所谓的进程、模块、执行线程了。「执行事实」

发生在执行线程身上，而不在进程身上。也就是说，CPU 排程单位是执行线程而非进程。排

程器据以排序的，是每个执行线程的优先权。

优先权的设定分为两个阶段。我已经在第１章介绍过。执行线程的「父亲大人」（进程）

拥有所谓的优先权等级（priority class，图1-7），可以在CreateProcess 的参数中设定。

执行线程基本上继承自其「父亲大人」的优先权等级，然后再加上CreateThread 参数中的微调差额（-2~+2）。获得的结果（图1-8）便是执行线程的所谓base priority，范围从0~31 数值愈高优先权愈高。::SetThreadPriority 是调整优先权的工具，它所指定的也是微调差

额（-2~+2）。

// 指向各个sections，

// 包括程序代码，资料，资源

图14-2 模块数据结构MDB 的细部内容（资料整理自Windows 95 System Programming SECRETS, Matt Pietrek, IDG Books）

执行线程排程(Scheduling)

排程器挑选「下一个获得CPU 时间的执行线程」的唯一依据就是：执行线程优先权。如果所有等待被执行的执行线程中，有一个是优先权16，其它所有执行线程都是优先权15（或更低），那么优先权16 者便是下一个夺标者。如果执行线程Ａ和Ｂ同为优先权16，排程器会挑选等待比较久的那个（假设为执行线程Ａ）。当Ａ的时间切片（timeslice）终了，如果Ｂ以外的其它执行线程的优先权仍维持在15（以下），执行线程Ｂ就会获得执行权。「如果Ｂ以外的其它执行线程的优先权仍维持在15（以下）...」，唔，这听起来彷佛优先

权会变动似的。的确是。为了避免朱门酒肉臭、路有冻死骨的不公平情况发生，排程器

会弹性调整执行线程优先权，以强化系统的反应能力，并且避免任何一个执行线程一直未能接受CPU 的润泽。一般的执行线程优先权是7，如果它被切换到前景，排程系统可能暂

时地把它调升到8 或9 或更高。对于那些有着输入消息等待被处理的执行线程，排程系

统也会暂时调高其优先权。

对于那些优先权本来就高的执行线程，也并不是有永久的保障权利。别忘了Windows 毕竟是个消息驱动系统，如果某个执行线程调用::GetMessage 而其消息队列却是空的，这个执行线程便被冻结，直到再有消息进来为止。冻结的意思就是不管你的优先权有多高，暂时退出排班行列。执行线程也可能被以::SuspendThread 强制冻结住（::ResumeThread 可以解除冻结）。

会被冻结，表示这个执行线程「要去抓取消息，而执行线程所附带的消息队列中却没有消息」。如果一个执行线程完全和UI 无关呢？是否它就没有消息队列？倒不是，但它的程序代码中没有消息循环倒是事实。是的，这种执行线程称为worker thread。正因它不可能会被冻结，所以它绝对不受Win16Mutex 或其它因素而影响其强制性多任务性质，及其优先权。Thread Context

Context 一词，我不知道有没有什么好译名，姑且就用原文吧。它的直接意思是「前后关系、脉络；环境、背景」。所以我们可以说Thread Context 是构成执行线程的「背景」。

那是指什么呢？狭义来讲是指一组缓存器值（包括指令指位器IP）。因为执行线程常常会

被暂停，被要求把CPU 拥有权让出来，所以它必须将暂停之前一刻的状态统统记录下

来，以备将来还可以恢复。

你可以在WINNT.H 中找到一个CONTEXT 数据结构，它可以用来储存Thread

Context 。::GetThreadContext 和::SetThreadContext 可以取得和设定某个执行线程的

context，因而改变该执行线程的状态。这已经是非常低阶的行为了。Matt Pietrek 在其

Windows 95 System Programming SECRETS 一书第10 章，写了一个Win32 API Spy 程式，就充份运用了这两个函数。

我想我们在操作系统层面上的执行线程学理基础已经足够了，现在让我们看看比较实际一点的东西。

从程序设计层面看执行线程

书籍推荐：如果要从程序设计层面来了解执行线程，Jim Beveridge 和Robert Wiener 合着的Multithreading Applications in Win32 （Win32 多线程程序设计/侯俊杰译/?峰出版）是很值得推荐的一份知识来源。这本书介绍执行线程的学理观念、程序方法、同步控制、资

料一致性的保持、C runtime library 的多线程版本、C++ 的多线程程序方法、MFC 中的多线程

程序方法、除错、进程通讯（IPC）、DLLs...，以及约50 页的实际应用。

书籍推荐：Jeffrey Richter 的Advanced Windows 在进程与执行线程的介绍上（第２章和第３章），也有非常好的表现。他的切入方式是详细而深入地叙述相关Win32 API 的规格

与用法。并举实例左证。

如何产生执行线程？我想各位都知道了，::CreateThread 可以办到。图14-4 是与执行线程有

关的Win32 API。

与执行线程有关的Win32 API 功能

AttachThreadInput 将某个执行线程的输入导向另一个执行线程CreateThread 产生一个执行线程

ExitThread 结束一个执行线程GetCurrentThread 取得目前执行线程的handle

GetCurrentThreadId 取得目前执行线程的ID

GetExitCodeThread 取得某一执行线程的结束代码（可用以决定执行线程是否已结束）

GetPriorityClass 取得某一进程的优先权等级

GetQueueStatus 传回某一执行线程的消息队列状态

GetThreadContext 取得某一执行线程的context

GetThreadDesktop 取得某一执行线程的desktop 对象

GetThreadPriority 取得某一执行线程的优先权

GetThreadSelectorEntry 除错器专用，传回指定之执行线程的某个selector 的

LDT 记录项

ResumeThread 将某个冻结的执行线程恢复执行

SetPriorityClass 设定优先权等级

SetThreadPriority 设定执行线程的优先权

Sleep 将某个执行线程暂时冻结。其它执行线程将获得执行权。

SuspendThread 冻结某个执行线程

TerminateThread 结束某个执行线程

TlsAlloc 配置一个TLS（Thread Local Storage）

TlsFree 释放一个TLS（Thread Local Storage）

TlsGetValue 取得某个TLS（Thread Local Storage）的内容

TlsSetValue 设定某个TLS（Thread Local Storage）的内容

WaitForInputIdle 等待，直到不再有输入消息进入某个执行线程中

图14-4 与执行线程有关的Win32 API 函数

注意，多执行线程并不能让程序执行得比较快（除非是在多CPU 机器上，并且使用支持

symmetric multiprocessing 的操作系统），只是能够让程序比较「有反应」。试想某个程

式在某个菜单项目被按下后要做一个小时的运算工作，如果这份工作在主执行线程中做，

而且没有利用PeekMessage 的技巧时时观看消息队列的内容并处理之，那么这一个小时

内这个程序的使用者接口可以说是被冻结住了，将毫无反应。但如果沉重的运算工作是

由另一个执行线程来负责，使用者接口将依然灵活，不受影响。

Worker Threads 和U I Threads

从Windows 操作系统的角度来看，执行线程就是执行线程，并未再有什么分类。但从MFC

的角度看，则把执行线程划分为和使用者接口无关的worker threads，以及和使用者接口

（UI）有关的UI threads。

基本上，当我们以::CreateThread 产生一个执行线程，并指定一个执行线程函数，它就是一

个worker thread，除非在它的生命中接触到了输入消息-- 这时候它应该有一个消息回

路，以抓取消息，于是该执行线程摇身一变而为UI thread。

注意，执行线程本来就带有消息队列，请看图14-3 的TDB 结构。而如果执行线程程序代码

中带有一个消息循环，就称为UI thread。

错误观念

我记得曾经在微软的技术文件中，也曾经在微软的范例程序中，看到他们鼓励这样的作

法：为程序中的每一个窗口产生一个执行线程，负责窗口行为。这种错误的示范尤其存在

于MDI 程序中。是的，早期我也沾沾自喜地为MDI 程序的每一个子窗口设计一个执

行线程。基本上这是错误的行为，要付出昂贵的代价。因为子窗口一切换，上述作法会导

至执行线程也切换，而这却要花费大量的系统资源。比较好的作法是把所有UI（User

Interface）动作都集中在主执行线程中，其它的「纯种运算工作」才考虑交给worker threads

去做。

正确态度

什么是使用多执行线程的好时机呢？如果你的程序有许多事要忙，但是你还要随时保持注意某些外部事件（可能来自硬件或来自使用者），这时就适合使用多执行线程来帮忙。

以通讯程序为例。你可以让主执行线程负责使用者接口，并保持中枢的地位。而以一个分离的执行线程处理通讯端口，

MFC 多线程程序设计

我已经在第１章以一个小节介绍了Win32 多线程程序的写法，并给了一个小范例MltiThrd。这一节，我要介绍MFC 多线程程序的写法。

探索CWinThread

就像CWinApp 对象代表一个程序本身一样，CWinThread 对象代表一个执行线程本身。这个MFC 类别我们曾经看过，第６章讲「MFC 程序的生死因果」时，讲到「CWinApp::Run - 程序生命的活水源头」，曾经追踪过CWinApp::Run 的源头CWinThread::Run（里面有

一个消息循环）。可见程序的「执行事实」系发生在CWinThread 对象身上，而CWinThread 对象必须要（必然会）产生一个执行线程。

我希望「CWinThread 对象必须要（必然会）产生一个执行线程」这句话不会引起你的误会，以为程序在application object（CWinApp 对象）的构造式必然有个动作最终调用到CreateThread 或_beginthreadex。不，不是这样。想想看，当你的Win32 程序执行起来，

你的程序并没有调用CreateProcess 为自己做出代表自己的那个进程，也没有调用CreateThread 为自己做出代表自己的主执行线程（primary thread）的那个执行线程。为你的程序产生第一个进程和执行线程，是系统加载器以及核心模块（KERNEL32）合作的结果。所以，再次循着第６章一步步剖析的步骤，MFC 程序的第一个动作是CWinApp::CWinApp

（比WinMain 还早），在那里没有「产生执行线程」的动作，而是已经开始在收集执行线程的相关信息了：

// in MFC 4.2 APPCORE.CPP

CWinApp::CWinApp(LPCTSTR lpszAppName)

{

...

// initialize CWinThread state

AFX_MODULE_STATE* pModuleState = _AFX_CMDTARGET_GETSTATE();

AFX_MODULE_THREAD_STATE* pThreadState = pModuleState->m_thread;

ASSERT(AfxGetThread() == NULL);

pThreadState->m_pCurrentWinThread = this;

ASSERT(AfxGetThread() == this);

m_hThread = ::GetCurrentThread();

m_nThreadID = ::GetCurrentThreadId();

...

}

虽然MFC 程序只会有一个CWinApp 对象，而CWinApp 衍生自CWinThread，但并不

是说一个MFC 程序只能有一个CWinThread 对象。每当你需要一个额外的执行线程，不应该在MFC 程序中直接调用::CreateThread 或_beginthreadex，应该先产生一个CWinThread 对象，再调用其成员函数CreateThread 或全域函数AfxBeginThread 将执行

线程产生出来。当然，现在你必然已经可以推测到，CWinThread::CreateThread 或AfxBeginThread 内部调用了::CreateThread 或_beginthreadex （事实上答案是

_beginthreadex）。

这看起来颇有值得商议之处：为什么CWinThread 构造式不帮我们调用AfxBeginThread 呢？似乎CWinThread 为德不卒。

图14-5 就是CWinThread 的相关源代码。

#0001 // in MFC 4.2 THRDCORE.CPP

#0002 CWinThread::CWinThread(AFX_THREADPROC pfnThreadProc, LPVOID pParam) #0003 {

#0004 m_pfnThreadProc = pfnThreadProc;

#0005 m_pThreadParams = pParam;

#0006

#0007 CommonConstruct();

#0008 }

#0009

#0010 CWinThread::CWinThread()

#0011 {

#0012 m_pThreadParams = NULL;

#0013 m_pfnThreadProc = NULL;

#0014

#0015 CommonConstruct();

#0016 }

#0017

#0018 void CWinThread::CommonConstruct()

#0020 m_pMainWnd = NULL;

#0021 m_pActiveWnd = NULL;

#0022

#0023 // no HTHREAD until it is created

#0024 m_hThread = NULL;

#0025 m_nThreadID = 0;

#0026

#0027 // initialize message pump

#0028 #ifdef _DEBUG

#0029 m_nDisablePumpCount = 0;

#0030 #endif

#0031 m_msgCur.message = WM_NULL;

#0032 m_nMsgLast = WM_NULL;

#0033 ::GetCursorPos(&m_ptCursorLast);

#0034

#0035 // most threads are deleted when not needed #0036 m_bAutoDelete = TRUE;

#0037

#0038 // initialize OLE state

#0039 m_pMessageFilter = NULL;

#0040 m_lpfnOleTermOrFreeLib = NULL;

#0042

#0043 CWinThread* AFXAPI AfxBeginThread(AFX_THREADPROC pfnThreadProc, LPVOID pParam,

#0044 int nPriority, UINT nStackSize, DWORD dwCreateFlags,

#0045 LPSECURITY_ATTRIBUTES lpSecurityAttrs)

#0046 {

#0047 CWinThread* pThread = DEBUG_NEW CWinThread(pfnThreadProc, pParam);

#0048

#0049 if (!pThread->CreateThread(dwCreateFlags|CREATE_SUSPENDED, nStackSize,

#0050 lpSecurityAttrs))

#0051 {

#0052 pThread->Delete();

#0053 return NULL;

#0054 }

#0055 VERIFY(pThread->SetThreadPriority(nPriority));

#0056 if (!(dwCreateFlags & CREATE_SUSPENDED))

#0057 VERIFY(pThread->ResumeThread() != (DWORD)-1);

#0058

#0059 return pThread;

#0060 }

#0061

#0062 CWinThread* AFXAPI AfxBeginThread(CRuntimeClass* pThreadClass,

#0063 int nPriority, UINT nStackSize, DWORD dwCreateFlags,

#0064 LPSECURITY_ATTRIBUTES lpSecurityAttrs)

#0065 {

#0066 ASSERT(pThreadClass != NULL);

#0067 ASSERT(pThreadClass->IsDerivedFrom(RUNTIME_CLASS(CWinThread)));

#0068

#0069 CWinThread* pThread = (CWinThread*)pThreadClass->CreateObject();

#0070

#0071 pThread->m_pThreadParams = NULL;

#0072 if (!pThread->CreateThread(dwCreateFlags|CREATE_SUSPENDED, nStackSize,

#0073 lpSecurityAttrs))

#0074 {

#0075 pThread->Delete();

#0076 return NULL;

#0077 }

#0078 VERIFY(pThread->SetThreadPriority(nPriority));

#0079 if (!(dwCreateFlags & CREATE_SUSPENDED))

#0080 VERIFY(pThread->ResumeThread() != (DWORD)-1);

#0081

#0082 return pThread;

#0083 }

#0084

#0085 BOOL CWinThread::CreateThread(DWORD dwCreateFlags, UINT nStackSize,

#0086 LPSECURITY_ATTRIBUTES lpSecurityAttrs)

#0087 {

#0088 // setup startup structure for thread initialization

#0089 _AFX_THREAD_STARTUP startup; memset(&startup, 0, sizeof(startup));

#0090 startup.pThreadState = AfxGetThreadState();

#0091 startup.pThread = this;

#0092 startup.hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL);

#0093 startup.hEvent2 = ::CreateEvent(NULL, TRUE, FALSE, NULL);

#0094 startup.dwCreateFlags = dwCreateFlags;

#0095 ...

#0096 // create the thread (it may or may not start to run)

#0097 m_hThread = (HANDLE)_beginthreadex(lpSecurityAttrs, nStackSize,

#0098 &_AfxThreadEntry, &startup, dwCreateFlags | CREATE_SUSPENDED, (UINT*)&m_nThreadID);

#0099 ...

#0100 }

图14-5 CWinThread 的相关源代码

产生执行线程，为什么不直接用::CreateThread 或_beginthreadex？为什么要透过

CWinThread 对象？我想你可以轻易从MFC 源代码中看出，因为

CWinThread::CreateThread 和AfxBeginThread 不只是::CreateThread 的一层包装，更做

了一些application framework 所需的内部数据初始化工作，并确保使用正确的C runtime

library 版本。源代码中有：

#ifndef _MT

... // 做些设定工作，不产生执行线程，回返。

#else

... // 真正产生执行线程，回返。

#endif //!_MT)

的动作，只是被我删去未列出而已。

接下来我要把worker thread 和UI thread 的产生步骤做个整理。它们都需要调用AfxBeginThread 以产生一个CWinThread 对象，但如果要产生一个UI thread，你还必须先定义一个CWinThread 衍生类别。

产生一个Worker Thread

Worker thread 不牵扯使用者接口。你应该为它准备一个执行线程函数，然后调用AfxBeginThread：

CWinThread* pThread = AfxBeginThread(ThreadFunc, &Param);

...

UINT ThreadFunc (LPVOID pParam)

{

...

}

CWinThread* AFXAPI AfxBeginThread(AFX_THREADPROC pfnThreadProc,

LPVOID pParam,

int nPriority = THREAD_PRIORITY_NORMAL,

UINT nStackSize = 0,

DWORD dwCreateFlags = 0,

LPSECURITY_ATTRIBUTES lpSecurityAttrs = NULL);

AfxBeginThread 事实上一共可以接受六个参数，分别是：

参数一pfnThreadProc 表示执行线程函数。参数二pParam 表示要传给执行线程函数的参

数。参数三nPriority 表示优先权的微调值，预设为THREAD_PRIORITY_NORMAL，也

就是没有微调。参数四nStackSize 表示堆栈的大小，默认值0 则表示堆栈最大容量为

1MB。参数五dwCreateFlags 如果为默认值0，就表示执行线程产生后立刻开始执行；如

果其值为CREATE_SUSPENDED，就表示执行线程产生后先暂停执行。之后你可以使用

CWinThread::ResumeThread 重新执行它。参数六lpSecurityAttrs 代表新执行线程的安全防

护属性。默认值NULL 表示此一属性与其产生者（也是个执行线程）的属性相同。

在这里我们遭遇到一个困扰。执行线程函数是由系统调用的，也就是个callback 函数，不

容许有this 指针参数。所以任何一般的C++ 类别成员函数都不能够拿来当做执行线程函

式。它必须是个全域函数，或是个C++ 类别的static 成员函数。其原因我已经在第６

章的「Callback 函数」一节中描述过了，而采用全域函数或是C++ static 成员函数，其

间的优劣因素我也已经在该节讨论过。

执行线程函数的类型AFX_THREADPROC 定义于AFXWIN.H 之中：

// in AFXWIN.H

typedef UINT (AFX_CDECL *AFX_THREADPROC)(LPVOID);

所以你应该把本身的执行线程函数声明如下（其中的pParam 是个指针，在实用上可以指

向程序员自定的数据结构）：

UINT ThreadFunc (LPVOID pParam);

否则，编译时会获得这样的错误消息：

有时候我们会让不同的执行线程使用相同的执行线程函数，这时候你就得特别注意到执行线程

函数使用全域变量或静态变量时，数据共享所引发的严重性（有好有坏）。至于放置在

堆栈中的变量或对象，都不会有问题，因为每一个执行线程自有一个堆栈。