Win32多线程程序开发笔记

一、核心对象

创建线程之后，一般我们都能拿到两个重要的值，一个是HANDLE，大部分与线程相关的API都需要它。另一个是线程ID，线程的ID是一个全局变量，用于独一无二表现系统某个线程。类似于AttachThreadInput()和PostThreadMessage（）就需要用到线程ID。但是为了安全防护的缘故，我们不能根据ID获取到HANDLE。

HANDLE被称为核心对象，它与GDI对象有很多相似的地方，前者由KERNEL32.dll管理，后者由GDI32.dll管理。GDI对象都由操作系统管理，通常我们不需要知道其数据格式，可以通过SelectObject或ReleaseObject处理GDI对象，windows隐藏了实现细节，只是给我们一个HDC或HBRUSH，那些都是对象handle。

而核心对象是以HANDLE为引用依据，与GDI的HBRUSH、HPEN、HDC以及其他种handles不同，只有一种handle可以代表核心对象。所谓的handle，其实是个指针，指向操作系统内存空间某样东西，那东西不允许我们直接取得，为的是系统的完整性与安全。win32核心对象清单如下：

• 进程（processes）
• 线程（threads）
• 文件（files）
• 事件（events）
• 信号量（semaphores）
• 互斥器（mutexes）
• 管道（pipes，分为named和anonymous两种）

GDI对象和核心对象之间一个重要的不同：GDI对象有单一拥有者，不是进程就是线程。核心对象可以有一个以上的拥有者，甚至可以跨进程。核心对象通过引用计数来追踪每一个拥有者，一旦引用计数降到0，核心对象即自动被摧毁。由于引用计数的设计，对象有可能在“产生该对象的进程”结束之后还继续幸存。

如果一个进程在结束之前没有针对它所打开的核心对象调用CloseHandle（），操作系统会自动把那些对象的引用计数下降1，虽然可以依赖操作系统做清除工作，然而逻辑上的清除工作是完全不同的一回事，特别是多个进程，因为系统不知道对象代表的意义，所以它不知道解构顺序是否重要。而且一直产生“worker线程”而不关闭HANDLE，如果有成千上万的核心对象留给系统去清理，这样的资源泄漏可能会对效率带来负担。还有一点，不能依赖“因线程的结束而清理所有被这一线程产生的核心对象”，许多对象，如文件，是被进程拥有，而不是线程。

CloseHandle（）唯一做的事情就是把引用计数减1，“线程核心对象”引用到的那个线程也会令核心对象开启，因此，线程对象的默认引用计数是2.

GetExitCodeThread（）将传回线程函数的返回值，若线程还在进行，他会返回TRUE，而参数lpExitCode应该是STILL_ACTIVE

结束主线程

程序启动后就执行的那个线程成为主线程，主线程有两个特点，第一：负责GUI程序中的主消息循环。第二：这一线程的结束（不论是因为返回，还是调用ExitThread（）），会使得程序中所有线程被强迫结束，程序也因此而结束。其他的线程没有机会做清理工作。

二、微软的多线程模型

win32强调线程分为GUI线程和worker线程，GUI线程负责建造窗口以及处理主消息循环，worker线程进行纯粹的运算工作，一般而言GUI线程绝不会去做那些不能马上完成的工作。如果worker线程也产生了一个窗口，那么就会有一个消息队列产生并附着到此线程上，于是worker变成了GUI线程，因此若worker需要处理输入或者输出，它应该授权给UI线程去完成。

三、线程等待

第一个等待技术是win32 Sleep（）函数，但这个函数并不总是有用，因为我们并不知道什么事情要等多久。第二个等待技术被称为busy loop(busy waits)，不断调用GetExitCodeThread（），直到结果不再是STILL_ACTIVE。busy loop通常是可以依赖的，但它有个重大缺陷：浪费CPU时间，因此不要在win32中使用busy loop。

待续...............................

........................................