Win32多线程程序设计

DLL 的运作方式和 Unix 中的 shared library 有很大的不同。虽然最后的 结果类似，但其机制并不相似。DLL 是一个链接实体，有它自己的实际 生存事实。DLL 有自己的数据，独立于进程之外；有它自己的模块识别 代码（ID），可以被静态链接，也可以被动态链接（译注）。 DLL 可以被静态链接也可以被动态链接”，意思是指DLL 的 explicitly linking 和 implicitly linking 两种方式。前者是在程序中很明显地以 LoadLibrary() 将 DLL 载入，后者是在链接时期静态链接 DLL 的一个“替身”，也就是其 import library（输入函数库，或者说是导入库）。

如果你使用 C runtime library（在DLL的源码中），那么你应该使用 DllMain() 名称。但如果你没有使用 C runtime library（这是很希罕的情况），你可以利用链接器选项 /ENTRY 定义你自己喜欢的函数名称。

任何时候，当一个进程载入或卸载一个DLL 时，DllMain() 函数会被调用。线程也是一样。当一个进程开始执行时，它所用到的每一个 DLL 的DllMain() 都会被系统调用之，并获得 DLL_PROCESS_ATTACH 消息。如果是线程开始执行，进程所用到的每一个 DLL 的 DllMain() 也都会被系统调用之，并获得 DLL_THREAD_ATTACH 消息。

DllMain() 分别被以 DLL_PROCESS_ATTACH 和 DLL_THREAD_ATTACH 各调用一次。这令我 惊讶，因为我明明有两个线程。噢，原来 Win32 定义的这个机制，使得每一 个程序的第一个线程调用 DllMain() 时，是以 DLL_PROCESS_ATTACH 调 用之。所有后续的线程才是以 DLL_THREAD_ATTACH 调用之。 第二个重点是，DllMain() 系在新线程的 context 中被调用。这一点非常 重要，因为你需要一个 context，才能够使用线程局部存储（TLS）

关于“DllMain() 在线程的 context 中被调用”这件事，有一些分歧。很 明显地，程序 MAIN1 从未直接调用 DllMain()。DllMain() 是自动被调用， 你可以视之为 CreateProcess()（那是 Windows 调用的）或 CreateThread()（那 是 MAIN1 调用的）的副作用。现在我们看看，如果有５个、10 个、甚至 20 个 DLLs 被附着到进程之中的情况。每当你启动一个新线程，每一个 DLLs 的 DllMain() 都会被调用。突然之间你发现多了好多预期之外的负担。 为了避免这个问题，Win32 提供了一个 DisableThreadLibraryCalls() 函 数。该函数只在 Windows NT 中才有，在 Windows 95 中没有效用。你可以 一一指定不需要通告消息的 DLLs。如果一个程序常常产生新的线程，这么一 点小小的最优化操作会节省不少的负担唷。

最后还有一个关于通告消息的特性是你必须知道的。如果 DllMain() 收到 DLL_PROCESS_ATTACH 时因不能够正确初始化而传回 FALSE，DllMain() 还是会收到 DLL_PROCESS_DETACH。因此，你必须非常小心地在 FALSE 被传回之前，将每一个有价值的变量初始化为一个已知状态，如此一来， DLL_PROCESS_DETACH 的处理函数才不会因为乱指的指针或是不合理的 数组索引而当掉。

由于上述讨论的那些题目，你必须因此非常小心地安排你的 DllMain() 函 数。理想中你最好是像我那样，写一些简单的驱动程序，确保 ATTACH 和 DETACH 通告消息都能够被正确地处理——甚至即使它们遗漏掉了或是乱了 次序。 i 如果进程调用 LoadLibrary 时，有一个以上的线程正在运行，那么 DLL_THREAD_ATTACH 不会针对每一个线程送出。（译注：只有调用 LoadLibrary 的那个线程才会发出） i DllMain() 不接受第一个线程的 DLL_THREAD_ATTACH， 而以 DLL_PROCESS_ATTACH 取代之。 i DllMain() 不接收任何因 TerminateThread() 而结束之线程的 DLL_THREAD_DETACH 通告消息。如果程序调用 exit(1) 或 ExitProcess() 结束自己，这种情况就会发生。

我们还没有完成对 DLL 进入点的讨论。Win32 设计之初，下面的问题必 须解决： 1. 线程１调用 LoadLibrary()，会送出 DLL_PROCESS_ATTACH。 2. 当 DLL 正在处理 DLL_PROCESS_ATTACH ， 线程２ 调用 LoadLibrary()，于是送出 DLL_THREAD_ATTACH。 3. DllMain()开始处理DLL_THREAD_ATTACH——在DLL_PROCESS _ATTACH 未完成之前。 一个 race condition 于焉诞生，操作系统不能给你任何帮助。为了解决这 个问题，Win32 必须依序调用所有 DLLs 的 DllMain() 函数。在一个进程之 中，一次只有一个线程能够执行一个 DLL 的 DllMain()。事实上，每一个线 程依次调用每一个附着的 DLLs 的 DllMain() 函数。 偶尔你会进入一种副作用之中。如果你在 DllMain() 内产生一个线程，该 线程可能没有办法在其他数个 DllMain() 完成之前顺利初始化它自己。因此， 你不可能在 DllMain() 中启动一个线程，等待它初始化，然后才继续执行下去。

若想要生产 DLLs 以便安全地在多线程环境中使用，下面是几个大方针： i 不要使用全局变量。用来储存 TLS 槽（slot）者例外。 i 不要使用静态变量。 i 如有必要，尽量使用 TLS（Thread Local Storage）。 i 如有必要，尽量使用你的堆栈。

虽然我们已经讨论过，使用多重线程比使用多重进程的好处，但还是可 能因为某些理由使你决定使用多重进程。我们之所以认为线程有很多优点， 主要因为它“重量很轻”，对于系统资源的冲击最小，能够快速启动和结 束。多重线程可以共享同一个地址空间和核心对象，所以很容易在它们之间 搬移数据。 相反地，进程的设计，在彼此防护上就严谨多了。如果一个进程死亡， 系统中的其他进程还是可以继续执行。对于某些应用而言，这样的健壮性 （robustness）或许值得花费比较多的额外负担（overhead）。因为如果多个 线程在同一个进程中运行，那么一个误入歧途的线程就可能把整个进程给毁 了。

另一个使用多重进程的理由是，当一个程序从一个作业平台被移植到另一个作业平台上。以 Unix 来说吧，Unix 不支持线程，但其进程的产生与结束的代价并不昂贵。因此，Unix 应用程序往往使用多个进程。如果要把它们移植为多线程模式，可能需要大改。在这种情况下，将程序移植到 Win32，可能需要成本效益上的妥协。

在同一个进程的不同线程之间搬移数据，最简单的一种做法就是利用消息队列。 如果你尝试在进程Ａ的线程中把一个 LPARAM（内含一个指针）交给进 程Ｂ，进程Ｂ有可能在使用这一指针时当掉。问题出在这个指针所指的数据乃 位于进程Ａ的地址空间中。进程Ｂ不可能看到这个地址空间，所以这个指针会 被以进程Ｂ的地址空间解释之。那当然是牛头不对马嘴了。 为解决这个问题，Windows 定义了一个消息，名为 WM_COPYDATA，专门 用来在线程之间搬移数据——不管两个线程是否同属一个进程。和其他所有的消息一样，你必须指定一个窗口，也就是一个 HWND，当做消息的目的地。所以欲接 收此消息的线程必须有一个窗口（译注：也就是它必须是个 UI 线程）。 WM_COPYDATA 消息的使用方式如下： SendMessage(hwndReceiver, WM_COPYDATA, (WPARAM)hwndSender, (LPARAM)&cds); LPARAM 参数 cds 必须指向一个特定的 Windows 数据结构： typedef struct tagCOPYDATASTRUCT { // cds DWORD dwData; DWORD cbData; PVOID lpData; } COPYDATASTRUCT, *PCOPYDATASTRUCT;

你必须使用 SendMessage() 传送 WM_COPYDATA ， 不能够使用PostMessage() 或任何其他变种函数如 PostThreadMessage() 之流。这是因为系统必须管理用以传递数据的缓冲区的生命期。如果你使用 PostMessage()，数据缓冲区会在接收端（线程）有机会处理该数据之前，被系统清除并摧毁。 缓冲区的生命期是一个重点。如果要把数据传送给一个以 CreateThread() 产生出来的线程，那块数据空间必须从 heap 中获得，因为线程将在 CreateThread() 返回之后开始执行（译注）。lpData 所指向的这块数据并不受 限于这种方式。因为你用的是 SendMessage() ， 你可以保证接收端在SendMessage() 返回之前一定已经完成其对数据的操作（译注：这是因为SendMessage 有同步特性），所以 lpData 所指的空间可以在 heap 之中，也可以在 stack 之中。 然而，接收端（线程）所获得的数据系属于系统。数据区块只是临时存在， 一旦消息被处理之后，立刻就会被清除。并且因为是系统拥有这块空间，它被 认为应该是只读（read only）属性。如果接收端（线程）需要改变数据内容， 或是需要储存一份比较久远的数据副本，接收端应该自行拷贝一份。

对于在进程之间搬移数据，WM_COPYDATA 技术非常简单，但有时候 你需要更高效率的技术。你需要让进程真正地共享数据，就像同一进程中的线 程一样，于是某个进程对该数据的改变，立刻就能够反应在另一个进程中。要 达到这一点，你必须使用 Win32 进程通讯技术中的最低阶一层：共享内存 （shared memory）。

设定一块共享内存区域（Shared Memory Area） 设定一块共享内存区域，需要两个步骤： 1. 产生一个所谓的 file-mapping 核心对象，并指定共享区域的大小。 2. 将共享区域映射到你的进程的地址空间中。 第一个步骤使用 CreateFileMapping() 函数。一般而言，这个函数允许你 存取一个文件，就好像它是内存中的数据一样，但是我们要使用的是另一个特 殊的模式，它会在页面文件（paging file）中产生一块空间，使任何一个进程 都可以根据其名称而存取到它。 为了从共享内存中获得一个指针，我们必须使用 MapViewOfFile()。

你们之中有些已经熟悉 CreateFileMapping() 的人可能会惊讶，为什么我使 用页面文件（paging file）而不使用文件系统中的某个文件。两个理由，第一， 如果使用文件系统中的文件，每个人都得同意其文件名称及其位置。这是多么没 有必要的琐屑事情。第二，如果机器当掉了的话，一个文件可能变得陈旧而无用， 徒占磁盘空间。如果你以页面文件提供共享内存，上述问题都不会发生。

匿名管道，命名管道等

如果要在 MFC 程序中产生一个线程，而该线程将调用 MFC 函数或使用 MFC 的任何数据， 那么你必须以 AfxBeginThread() 或CWinThread::CreateThread() 来产生这些线程。

MFC使得对话框的产生极为简单。它也实现出消息派送系统（ message dispatching），处理 WPARAM 和 LPARAM 的易犯错误。MFC 甚至是引诱某些人进入 C++ 的原动力。

你已经看过了 worker 线程和 GUI 线程之间的一些理论上的差异。两者一般而言都是以 CreateThread() 或 _beginthreadex() 开始其生命。如果线程调用 GetMessage() 或 CreateWindow() 之类函数，消息队列便会产生（译注），而 worker 线程也就摇身一变成了 GUI 线程（或称为 UI 线程）。

MFC 对这两种线程有重大的区别。虽然两种线程都是以AfxBeginThread() 启动，但是 MFC 利用 C++ 函数的 overloading 性质，对该函数提供了两种不同的声明。编译器会根据你所提供的参数，自动选择正确的一个来用。

CWinThread 被极其小心地设计，解决了许多我们在 CreateThread() _beginthreadex() 中所遇到的困难。CWinThread 甚至正确地处理了原本期望_beginthread() 所做的清理（cleanup）工作。视你的需求，CWinThread 可以极有弹性。

让我们先花一些时间来比较 Win16 和 Win32 两者的消息队列。在 Win16 中，所有窗口共享同一个消息队列。如果某个程序停止处理消息队列中 的数据（也就是消息），那么所有的窗口就都会停止回应。这在 Windows 3.x 中是一个严重的问题，也是系统之所以会被锁死而不再做出反应的最大原因。 在 Win32 中，每一个线程有它自己专属的消息队列。这并不意味着每一 个窗口有它自己的消息队列，因为一个线程可以产生许多窗口。如果一个线程 停止回应，或是它忙于一段耗时的计算工作，那么由它所产生的窗口统统都会 停止回应，但系统中的其他窗口还是继续正常运作。

所有传送给某一窗口之消息，将由产生该窗口之线程负责处理。 你对窗口所做的任何一件事情基本上都会被该窗口的窗口函数（那个CALLBACK函数，窗口回调）处理，并因此被产生该窗口的线程处理。

当你进入一个窗口函数时，如果观察 Windows NT 中的调用堆栈（call stack），通常总是可以追踪回到 WinMain()，那是你的程序的起始点（Windows 95 则因为 16-bit thunking（译注）的缘故，故事不是这样发展）。你会在调用 堆栈（call stack）中看到某些函数位于 USER32.DLL 或 KERNEL32.DLL 之 中。这些函数用来将消息派送（dispatch）到适当的窗口函数去，并调用该窗 口函数。

所谓 thunking，可以说是一种转换，把 16 位函数调用（包括其中的参数以 及参数所代表或隐含的地址等等）转换为 32 位函数调用。或是反向转换。 16 位转为 32 位称为 thunk up，32 位转为 16 位称为 thunk down，而其间 的转换机制称为 thunking layer。

请注意，当你“send”一个消息给另一线程所掌握的窗口时，会发生什么 事情？系统必须做一次 context switch，切换到另一线程去，调用该窗口函数， 然后再做一次 context switch 切换回来。与一般的函数调用比起来，其间的额 外负担毋宁说是太大了些。 这个巨大的额外负担正是为什么“每个 MDI 窗口不应该有一个线程” 的头号原因。其间的牵连倒不是立刻就能浮现出来，毕竟一个 MDI 程序背后 的观念是要让每一个窗口能够独立工作，所以似乎不会喜欢让各个窗口间常有 沟通。问题出在主窗口！ 时髦的 Windows 程序往往挂上一大堆琳琅满目的“勋章”：工具栏（toolbars）啦、状态栏（status bars）啦、调色板（palettes）啦。它们统统必须被处理、被更新状态、被致能（enabled）或除能（disabled）。这些动作通常由目前作用中的子窗口负责，因为这些“勋章”的状态系由作用中的 子窗口决定。在 MFC 中，这个行为已经被 OnUpdate() 完全承担下来。如果这些“勋章”存活于不同的线程中，那么更新其状态可能需要数百次 context switches。这样的结果将对效率带来严重的冲击。

有一件事情很重要，必须了解：当你“send”一个消息出去时，你的线程 将暂时处于睡眠状态。这使得 SendMessage() 就像一个典型的函数调用操作。 虽然你的线程正在等待 SendMessage() 的返回，但它还是可以处理外界对 其拥有之窗口的任何 SendMessage() 调用操作，甚至即使线程不处于主消息循 环（其中有 GetMessage() 和 DispatchMessage() 操作）之中。如果 Windows 不 这样设计，那么该线程所拥有的其他任何窗口就会停止反应，并且无法回答来 自外界的任何 SendMessage() 操作。

虽然 waiting thread 可以处理来自 SendMessage() 的消息，但它不处理其 他种类（像是位于消息队列中）的消息。如果 destination thread 开启一个对话 框（译注：会将其父窗口除能的那种，也就是“modal dialog”），或是进入 一个消息循环中，以至于没有返回至 waiting thread 的 SendMessage() 调用 处，那么就可能引起一些问题。为了解决这问题，当 destination thread 调用以 下任何函数，waiting thread 必须自动醒来： DialogBox() DialogBoxIndirect() DialogBoxIndirectParam() DialogBoxParam() GetMessage() MessageBox() PeekMessage() 我们可以测试一个线程（译注：也就是前述的 waiting thread）是否正陷于 “SendMessage() 未返回”的进退维谷情况中，而且可以明白地让调用端（译 注：也就是前述的 waiting thread）醒来。这可能是有用的——如果你需要开始 一个长时间的计算工作，而发动计算的那个人（线程）不需要知道其结果的话。 如果某个线程（译注：也就是前述的 destination thread）正在处理由其他 线程“sent”过来的消息，所以你在该线程中调用 IsSendMessage()，会获得 TRUE。IsSendMessage() 不需要指定参数。 为了让调用端线程（译注：也就是前述的 waiting thread）能够继续工作， 我们可以调用 ReplyMessage()。

当 Windows 必须在线程之间“send”消息时，不论是否这些线程位于相 同进程之中，总是有这种可能：destination thread 被锁死，以至于 waiting thread 永远醒不过来。 这个问题在你跨越进程“send”消息时特别突出，因为你没有办法保证传 送对象（目标线程）的行为。Win32 提供了两个函数协助解决这个问题。 第一个函数是 SendMessageTimeout()。它允许你指定一个时间，时间终了 后不管对方怎么样，SendMessageTimeout() 一定会返回。如果对方“挂”了， 它也会自动返回。 第二个函数是 SendMessageCallback()。这个函数会立刻返回，但其参数 之一，一个函数地址，应该被以 SendMessage() 的方式调用起来。

欲在一个 MDI 程序中有效率地使用多个线程，我的建议是，以一个线程处理所有的用户输入，以及所有用户界面的管理，然后使用一个以上的线程来负责诸如重绘、打印等工作。或许你还需要一些线程，用来处理你的磁盘I/O或网络 I/O。不管你如何切割你的工作，很重要的一点是，你的主线程（负责主框架窗口）总是应该能够有所回应，不会陷入长时间计算的泥淖中。

线程常常需要将数据传递给另一个线程。Worker 线程可能需要告诉别人说它的工作完成了，GUI 线程则可能需要交给 worker 线程一件新工作。 PostThreadMessage() 的操作就像 PostMessage() 一样，但是它的参数之一不是窗口 handle，而是线程 ID。当然，收受端线程必须有消息队列，不过至少这个队列是由操作系统管理，你不必操心。

PostThreadMessage() 把消息“post”给一个线程，而非一个窗口。如果收受端线程尝试获取目标窗口的 handle，它会得到 NULL。所以，收受端线程的消息循环应该有特殊的处理方式，以处理窗口函数之外的消息。以消息当做通讯方式，比起标准技术如使用全局变量等，有很大的好处。 如果目标线程很忙碌，则负责“post”的那个线程不会因此停滞下来。

如果对象是同一进程中的线程，你可以自定义消息，如WM_APP + 0x100等等，并配置一块结构，放置你想传递的数据，然后把结构指针当做lParam。收受端应该在处理完消息后负责释放内存。 如果你使用 PostThreadMessage() 在不同进程的线程之间传递消息，你必须使用 WM_COPYDATA 消息，这样一来数据才能够从一个地址空间中被映射到另一个地址空间。