学习多线程编程面临的最大的思维方式的转变有两点：
- 当前线程可能随时会被切换出去，或者说被抢占了
- 多线程程序中事件的发生顺序不再有全局统一的先后关系
多线程程序的正确性不能依赖于任何一个线程的执行速度，不能通过原地等待来假定其他线程的事件已经发生，而必须通过适当的同步来让当前线程能够看到其他线程事件的结果。无论线程执行得快与慢（被操作系统切换出去得越多，执行越慢），程序都应该能够正常工作。
1. 基本线程原语的选用
本书只谈现代 linux 下的多线程编码。11最基本的 Pthreads 函数是：
- 2个：线程创建和等待结束（join）。
- 4个：mutex 的创建、销毁、加锁、解锁。
- 5个：条件变量的创建、销毁、等待、通知、广播。
多线程系统编程的难点不在于学习线程原语，而在于理解多线程与现有的C/C++库函数和系统调用的交互关系，以进一步学习如何设计并实现线程安全且高效的程序。
2. C/C++系统库的线程安全性
我们不必担心系统调用的线程安全性，因为系统调用对于用户态程序来说就是原子的。但是要注意系统调用对于内核状态的改变可能影响其他线程。
可以说现在的 glibc 库函数大部分都是线程安全的。特别是FILE* 系列函数是安全的，glibc 甚至提供了费线程安全版本以应对某些特殊场合的性能需求。
尽管单个函数是线程安全的，但两个或多个函数放到一块就不再安全了。线程安全程序的一个难点在于线程安全是可组合的，一个函数 foo() 调用了两个线程安全的函数，而这个 foo() 函数本身很可能不是线程安全的。即便大多数 glibc 库函数是线程安全的，我们也不能像写单线程程序那样编写代码。
例如，在单线程程序中，如果我们要临时转换时区，可以用txset() 函数，这个函数会改变程序全局的“当前时区”。
//获取伦敦的当前时间
string oldTz = getenv("TZ"); //save TZ,assumeing non-NULL
putenv("TZ=Europe/London"); //set TZ to London
tzset(); //load London time zone
struct tm localTimeInLN;
time_t now = time(NULL); //get time in UTC
localtime_r(&now, &localTimeInLN); //convert to London local time
setenv("TZ", oldTz.c_str(), 1); //restore old TZ
tzset(); //local old time zone
但是在多线程程序中，这么做是不安全的，即便tzset() 本身是线程安全的。因为他改变了全局状态，这有可能影响其他线程转换当前时间，或者被其他进行类似的操作的线程影响。解决办法是使用mudou::TimeZone class ，每个immutable instance 对应一个时期，这样时间转换就不需要修改全局状态了。例如：
class TimeZone
{
public:
explict TimeZone(const char* zonefile) ;
struct tm toLocalTime(time_t secondsSinceEpoch)const;
time_fromLocalTime(const struct tm&)const;
// default copy ctor /assigment /dtor are okay.
// ...
};
const TomeZone kNewYorkTz("/usr /share / zoneinfo / America /New_York”）
const TomeZone kLondonTz( " /usr / share / zoneinfo /Europe / London’’）
time_t now=time(NULL)
struct tm locaTimeInNY= kNewYorkTz.toLcalTime(now);
struct tm localTimeInLN = kLondonTz. toLocalTime (now);
对于c/c++库的作者来说，符合设计线程安全的接口也成了一大考验，值得效仿的例子并不多。一个基本的思路尽量吧class 设计成immutable 的，这样用起来就不必为线程安全操心了。
尽管c++03标准没有明说标准库的线程的安全性，但我们可以遵循一个基本的原则：凡是非共享的对象都是彼此独立的，如果一个对象从始至终只被一个线程用到，那么它就是安全的。
3. Linux 上的线程标识
POSIX threads 库提供了 pthread_self 函数用于返回当前进程的标识符，其类型为 pthread_t。pthread_t 不一定是一个数值类型，也有可能是一个结构体。这就带来了一些列问题，包括：
- 无法打印输出 pthread_t， 因为不知道其确切数据类型，也没有办法在日志中记录用它标识的当前线程的id。
- 无法比较 pthread_t 的大小或计算其 hash 值，因此无法用于关联容器的 key。
- 无法定义一个非法的 pthread_t 值，用来标识绝不可能存在的线程 id，因此MutexLock class 没有办法判断当前线程是否已经持有本锁。
- pthread_t 值只在进程内有意义，与操作系统的任务调度之间无法建立有效关联。比方说在/proc 文件系统中找不到 pthread_t 对应的 task。
另外，glibc 的 Pthreads 实际上把 pthread_t 用作一个结构体指针（它的类型是unsiged long），指向一块动态分配的内存，而且这块内存是反复使用的。这就造成 pthread_t 的值很容易重复。Pthreads 只保证同一进程内，同一时刻的各个线程的 id 不同；不能保证同一进程先后多个进程具有不同的 id，更不要说一台机器上多个进程之间的唯一性了。
例如下面这段代码中先后两个线程的标识符是相同的：
int main()
{
pthread_t t1, t2;
pthread_create(&t1, NULL, threadFunc, NULL);
printf("%lx\n", t1);
pthread_join(t1, NULL);
pthread_create(&t2, NULL, threadFunc, NULL);
printf("%lx\n", t2);
pthread_join(t2, NULL);
}
运行结果如下所示：
./a.out
7fad11787700
7fad11787700
因此，pthread_t 并不适合用作程序中对线程的标识符。
在linux上，建议使用 gettid(2) 系统调用的返回值作为线程id，这么做的好处有：
- 它的类型是pid_t，其值通常是一个小整数，便于在日志中输出。
- 在现代 linux 中，它直接表示内核的任务调度id，因此在 /proc 文件系统中可以轻易地找到对应项。
- 在其他系统工具中也容易定位到具体某一线程，例如在 top(1) 中我们可以按线程列出任务。
- 任何时刻都是全局唯一的，并且由 linux 分配新 pid 采用递增轮回办法，短时间内启动多个线程也不会具有不同的线程id。
- 0是非法值，因为操作系统第一个进程init 的 pid 是1。
4. 线程创建于销毁的守则
线程的创建于销毁是编写多线程程序的基本要素，线程的创建比销毁要容易的多，需要遵守的原则：
- 程序库不应该在未提前告知的情况下创建自己的“背景线程”。
- 尽量用相同的方式创建线程。
- 在进入 main() 函数之前不应启动线程
线程的销毁有几种方式：
- 自然死亡。从线程主函数返回，线程正常退出。
- 非正常死亡。从线程主函数抛出异常或线程触发 segfault 信号等非法操作。
- 自杀。在线程中调用 pthread_exit() 来立刻退出线程。
- 他杀。其他线程调用pthread_cancel()来强制终止某个线程。
5. 善用_ _thread 关键字
_ _thread 是GCC 内置的线程局部存储设施。它的实现非常高效，比pthread_key_t 快很多，其存取效率可与全局变量相比。
_ thread 使用规则：只能用于修饰POD类型，不能修饰class类型，因为无法自动调用构造函数和析构函数。 thread 可以用于修饰全局变量、函数内的静态变量，但是不能用于修饰函数的局部变量或者class的普通成员变量。另外， _thread 变量的初始化只能用编译期常量。
_ _thread 变量是每个线程有一份独立实体，各个线程的变量值互不干扰。除了这个主要用途，它还可以修饰那些 “值可能会变，带有全局性，但是又不值得用全局锁保护”的变量。
6. 多线程与IO
操作文件描述符的系统调用本身是线程安全的，我们不用担心多个线程同时操作会造成进程崩溃或内核崩溃。
但是，多个进程同时操作同一个socket 文件描述符确实很麻烦，我认为是得不偿失的。需要考虑的情况如下：
- 如果一个线程正在阻塞地 read(2) 某个 socket，而另一个线程 close(2) 了此socket。
- 如果一个线程正在阻塞地accept(2)某个listening socket，而另一个线程close(2)了此socket。
- 一个线程正准备 read(2) 某个 socket，而另一个线程close(2)了此socket；第三个线程又正好 open(2) 了另一个文件描述符，其fd号码正好与前面的socket 相同，这样程序逻辑就混乱了。
