很抱歉，本文谈不上是什么文章，只是一点点在C++论坛上提出的心得，之所以摘录到这里的原因有二：一为论坛上和者众而异者少，我渴望在这里听到批评的声音；二为从未有在这里发表文章的经验，有些好奇 ：-)
主题：
线程是个什么东西？
作者：
等级：
信 誉 值：
110
所属论坛：
C/C++
问题点数：
200
回复次数：
28
发表时间：
2002-8-6 20:41:20
最初接触线程是通过 WIN32 API CreateThread，觉得很简单，线程就是一个执行线索，进程中可以有一个或多个线索。后来接触到了MFC CWinThread，用起来也挺方便的。再后来由于工作的关系，基本不用MFC了，转向了跨平台C++编程，于是仿照CWinThread设计了一个线程类，还挺得意。
如今渐渐觉得这样的线程类增加了软件的耦合度，由于存在这样的线程类，忍不住就将很多业务逻辑放到其中，这几乎是无法抵挡的诱惑。但是这样一来，一旦调度策略发生变化，就要花费很多精力将业务逻辑从线程类中剥离出来。
看了Boost::thread，很受启发，它将线程对象和线程的入口完全地隔离开了。刚开始还有点不习惯，不过这样的设计肯定有其道理。线程其实就是一个调度的线索，只有将其和业务对象隔离开来，才有可能使调度策略和业务逻辑得以各自独立地发生改变。
举个例子，在网络编程中，服务端经常有这样的设计，主线程监听端口，对每个客户启动一个线程，于是就可能产生 ClientThread 这样的类，这个设计的优点是简洁，不过随着业务的扩充，可能无法启动足够的客户线程，必须更改设计，让一个线程同时处理多个客户，痛苦来临了，必须把先前的 ClientThread 中的Client提取出来。如果我们一开始就强制地禁止出现ClientThread，而代之以Client和Thread两个对象，一切就清晰多了。
以上是初步的感想，还没有深思。希望大家来讨论。
回复人： anrxhzh(百宝箱) (
2002-8-8 14:00:53
得分:0
class thread : private noncopyable
{
public:
thread();
explicit thread(const function0<void>& threadfunc);
~thread();
bool operator==(const thread& other) const;
bool operator!=(const thread& other) const;
void join();
}
这是boost的线程类。第一次见到它，挺高兴，这么简单，肯定可靠，可以在其上为所欲为了。要知道我最初设计的线程类可谓功能强大，可以暂停、恢复、终止、启动、记日志，甚至还可以建立线程树，向GUI传送通知信息和运行状态，现在回想起来简直后怕。如今想来，线程就是一个调度线索，boost::thread 提供的接口已经差不多了，接口越多越有害。
言规正传，boost::thread 有几个与众不同的设计：
1. threadfunc 和 thread 是分离的，并不是一个虚方法。
2. threadfunc 的原型是 void f()，而不是 void f(void*)。
3. threadfunc 可以是一个函数对象，并且thread会在内部保存一份该对象的拷贝，这个拷贝的生命期不小于线程的存活期。
为什么要这样设计呢，希望大家来讨论。先简单地谈一下我的看法：
1.我提问的帖子已经回答了，这是为了强制地将调度策略和业务逻辑分离。
2.void f(void*)不可靠，void f(void)可以强制地让你改善程序的设计。
3.持保留态度。我测试了一下，如果thread object在线程存活期内被销毁，拷贝将不会被释放。当然，如果调用了join()就不会存在这个问题了，不过这到底是个局限。更为重要的是，函数对象必须提供拷贝构造函数，这个局限就更大了，有些类是无法提供拷贝构造函数的。