Threads

如 ORACLE 9i FOR LINUX 是在标准的 Linux Threads 下开发的，当在 Redhat Linux(kernel 2.6)中安装的时候，必须设定 LD_ASSUME_KERNEL 为 2.4.0，以让 Redhat Linux 使用标准的 Linux Threads，否则安装进度指示条一直停留在开始处。

使用互斥量时，应该小心死锁。

当线程 A 占有了互斥量 mutex1，想要占有互斥量 mutex2；而同时，线程 B 占有了互斥量 mutex2，想要占有互斥量 mutex1，这时就会产生死锁。

可以通过仔细控制互斥量加锁的顺序来避免死锁的发生。如上面例子中，如果所有线程总是在对互斥量 mutex2 加锁之前锁住互斥量 mutex1，那么就不会产生死锁。
但有时候，应用程序的结构可能使得对互斥量排序很困难，这时可以使用 pthread_mutex_trylock 来避免死锁。

参考：UNIX 环境高级编程(第 3 版)，11.6.2 节 避免死锁

下面用一个实例来说明条件变量为什么有用。实例摘自：The Linux Programming Interface, 30.2.2 Signaling and Waiting on Condition Variables

假设有两个线程，一个线程（设为线程 B）用来生产某种部件，而主线程（设为线程 A）用来消耗它。

static pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
static int avail = 0;                /* 记录当前可用 unit 的数量 */

生产部件线程（线程 B）的主要代码如下所示：

/* 生产某部件的代码省略 */

pthread_mutex_lock(&mtx);
avail++;
pthread_mutex_unlock(&mtx);

消耗部件的主线程（线程 A）的主要代码如下所示：

for (;;) {
  pthread_mutex_lock(&mtx);
  while (avail > 0) {      /* 在while循环中消耗所有可用的部件 */
    /* 消耗部件的代码省略 */
    avail--;
  }
  pthread_mutex_unlock(&mtx);

  /* Perhaps do other work here that doesn't require mutex lock */
}

上面的代码可以工作。
但它有一个不足：浪费 CPU 资源。主线程（线程 A）在 for 循环里不停地检查有没有可用的部件（测试变量 avail 是否大于 0），如果此时线程 B 还没有生产出部件，线程 A 可能会一直重复“加锁——发现没有工作可做——解锁”这个过程，这浪费了 CPU 资源。“条件变量”可以解决这个浪费 CPU 资源问题，基本思路是线程 A 发现没有工作可做时就阻塞，直到线程 B 生产出可用部件后通知它。

条件变量总和互斥量一起使用，互斥量用来实现对共享变量的互斥访问，条件变量用来通知共享变量的改变。

下面用条件变量来解决上面问题。

  static pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
+  static pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
  static int avail = 0;                /* 记录当前可用 unit 的数量 */

使用条件变量后，生产部件线程（线程 B）的主要代码如下所示：

  /* 生产某部件的代码省略 */

  pthread_mutex_lock(&mtx);
  avail++;
  pthread_mutex_unlock(&mtx);
+  pthread_cond_signal(&cond);     /* 发会通知，唤醒等待在该条件变量上的线程 */

使用条件变量后，消耗部件的主线程（线程 A）的主要代码如下所示：

 1: for (;;) {
 2:   pthread_mutex_lock(&mtx);
 3: +  while (avail == 0) {
 4: +    pthread_cond_wait(&cond, &mtx); /* 3个作用：(1) 解锁互斥量mtx */
 5: +                                    /* (2) 阻塞线程直到另外的线程通过条件变量cond唤醒它 */
 6: +                                    /* (3) 再次对互斥量mtx加锁 */
 7: +  }
 8:   while (avail > 0) {      /* 在while循环中消耗所有可用的部件 */
 9:     /* 消耗部件的代码省略 */
10:     avail--;
11:   }
12:   pthread_mutex_unlock(&mtx);
13: 
14:   /* Perhaps do other work here that doesn't require mutex lock */
15: }

注 1：为什么上面代码中第 3 行使用 while 而不是 if 来检测条件 (avail == 0) 呢？这是为了避免“虚假唤醒”（Spurious wakeup）。在 pthread_cond_wait 的文档中有相关说明：

Spurious wakeups from the pthread_cond_wait() or pthread_cond_timedwait() functions may occur. Since the return from pthread_cond_wait() or pthread_cond_timedwait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return.

不过，就前面的例子来说，第 3 行使用 if 也行，因为后面（即第 8 行）再次对 avail 进行了检测，就算出现了虚假唤醒，也只是浪费了 CPU，不影响逻辑。

注 2：再次强调，函数 pthread_cond_wait(&cond, &mtx)执行三个步骤：
(1) 解锁互斥量 mtx；
(2) 阻塞线程直到另外的线程通过条件变量 cond 唤醒它，例如，其他线程调用 pthread_cond_signal(&cond)或者 pthread_cond_broadcast(&cond)；
(3) 再次对互斥量 mtx 加锁。

显然， 在调用 pthread_cond_wait(&cond, &mtx)之前，互斥量 mtx 必须已经被锁定。

参考： man pthread_cond_wait

条件变量相关 pthread 函数如表 5 所示。

生产者—消费者问题的信号量解法和条件变量解法如下：

+---------------------------------------------+------------------------------------------------------------------+
|Producer-Consumer Problem (Using Semaphores) |Producer-Consumer Problem (Using Condition Variables)             |
+---------------------------------------------+------------------------------------------------------------------+
|typedef struct {                             |typedef struct {                                                  |
|    char buf[BSIZE];                         |     char buf[BSIZE];                                             |
|    sem_t occupied;                          |     int occupied;                                                |
|    sem_t empty;                             |     int nextin;                                                  |
|    int nextin;                              |     int nextout;                                                 |
|    int nextout;                             |     pthread_mutex_t mutex;                                       |
|    sem_t pmut;                              |     pthread_cond_t more;                                         |
|    sem_t cmut;                              |     pthread_cond_t less;                                         |
|} buffer_t;                                  |} buffer_t;                                                       |
|                                             |                                                                  |
|buffer_t buffer;                             |buffer_t buffer;                                                  |
|                                             |                                                                  |
|sem_init(&buffer.occupied, 0, 0);            |                                                                  |
|sem_init(&buffer.empty,0, BSIZE);            |                                                                  |
|sem_init(&buffer.pmut, 0, 1);                |                                                                  |
|sem_init(&buffer.cmut, 0, 1);                |                                                                  |
|buffer.nextin = 0;                           |                                                                  |
|buffer.nextout = 0;                          |                                                                  |
|                                             |                                                                  |
+---------------------------------------------+------------------------------------------------------------------+
|void producer(buffer_t *b, char item) {      |void producer(buffer_t *b, char item) {                           |
|    sem_wait(&b->empty);                     |    pthread_mutex_lock(&b->mutex);                                |
|    sem_wait(&b->pmut);                      |                                                                  |
|                                             |    while (b->occupied >= BSIZE)                                  |
|    b->buf[b->nextin] = item;                |        pthread_cond_wait(&b->less, &b->mutex);                   |
|    b->nextin++;                             |                                                                  |
|    b->nextin %= BSIZE;                      |    assert(b->occupied < BSIZE);                                  |
|                                             |                                                                  |
|    sem_post(&b->pmut);                      |    b->buf[b->nextin] = item;                                     |
|    sem_post(&b->occupied);                  |    b->nextin++;                                                  |
|}                                            |    b->nextin %= BSIZE;                                           |
|                                             |    b->occupied++;                                                |
|                                             |                                                                  |
|                                             |    /* now: either b->occupied < BSIZE and b->nextin is the index |
|                                             |       of the next empty slot in the buffer, or                   |
|                                             |       b->occupied == BSIZE and b->nextin is the index of the     |
|                                             |       next (occupied) slot that will be emptied by a consumer    |
|                                             |       (such as b->nextin == b->nextout) */                       |
|                                             |                                                                  |
|                                             |    pthread_cond_signal(&b->more);                                |
|                                             |                                                                  |
|                                             |    pthread_mutex_unlock(&b->mutex);                              |
|                                             |}                                                                 |
|                                             |                                                                  |
+---------------------------------------------+------------------------------------------------------------------+
|char consumer(buffer_t *b) {                 |char consumer(buffer_t *b) {                                      |
|    char item;                               |    char item;                                                    |
|                                             |    pthread_mutex_lock(&b->mutex);                                |
|    sem_wait(&b->occupied);                  |    while(b->occupied <= 0)                                       |
|    sem_wait(&b->cmut);                      |        pthread_cond_wait(&b->more, &b->mutex);                   |
|                                             |                                                                  |
|                                             |    assert(b->occupied > 0);                                      |
|    item = b->buf[b->nextout];               |                                                                  |
|    b->nextout++;                            |    item = b->buf[b->nextout];                                    |
|    b->nextout %= BSIZE;                     |    b->nextout++;                                                 |
|                                             |    b->nextout %= BSIZE;                                          |
|    sem_post(&b->cmut);                      |    b->occupied--;                                                |
|    sem_post(&b->empty);                     |                                                                  |
|                                             |    /* now: either b->occupied > 0 and b->nextout is the index    |
|                                             |       of the next occupied slot in the buffer, or                |
|    return(item);                            |       b->occupied == 0 and b->nextout is the index of the next   |
|}                                            |       (empty) slot that will be filled by a producer (such as    |
|                                             |       b->nextout == b->nextin) */                                |
|                                             |                                                                  |
|                                             |    pthread_cond_signal(&b->less);                                |
|                                             |    pthread_mutex_unlock(&b->mutex);                              |
|                                             |                                                                  |
|                                             |    return(item);                                                 |
|                                             |}                                                                 |
+---------------------------------------------+------------------------------------------------------------------+

说明：在信号量解法中，结构体 buffer_t 中信号量 pmut 和 cmut 的作用其实就是互斥量（直接使用互斥量效率更高，如果可以确保整个程序中最多只有一个生产者和最多只有一个消费者，则 pmut 和 cmut 相关代码都可以去掉），这里仅仅是为了演示信号量的用法。

一般来说，在线程中用条件变量就足够处理绝大部分的同步问题。

The semaphore uses more memory than the condition variable. The semaphore is easier to use in some circumstances because a semaphore variable operates on state rather than on control.

参考：Multithreaded Programming Guide, Comparing Primitives: http://docs.oracle.com/cd/E19253-01/816-5137/sync-31059/index.html

对于 TLS 的用途，Unix/Linux 的 C 程序库 libc 中的全局变量 errno 是个最典型的例子。

if (open (filename, mode) < 0) {
    error (0, errno, "%s", infile);  //全局变量erron可能被多个线程修改！
    // other code
}

当系统调用从内核返回用户空间时，如果 EAX 的值为 0xfffff001 至 0xffffffff 之间即为出错，取其负值(2 的补码)就是出错代码。此时将出错代码写入一个全局量 errno，以供进一步查验，并将 EAX 的值改成-1。这就是从 Unix 时代初期就定下的对于返回整数的系统调用的约定。其好处是写程序时可以略微方便一些，不用每次都在函数中定义一个局部变量 err，再写成“if ((err=open(filename, mode)) < 0”、并因为系统调用出错返回的几率毕竟很小。

在线程的概念出现之前，或者说在一个进程只含有一个线程的时代，这样安排不会有什么问题。这是因为，从启动系统调用的 C 库函数把出错代码写入全局量 errno 以后，到调用者发现返回值为-1、因而从 errno 获取出错代码的这一段时间中 errno 的值不可能改变。即使在这中间发生了中断、并且导致进 程调度，从当事进程的角度看也只是时间上的短暂停滞，却不会有谁来改变 errno 的内容；因为全局量 errno 是归进程所有，别的进程不会来打扰。

但是，有了多线程的概念和技术以后，情况就不一样了。因为同一进程中的多个线程是共享一个用户空间的，如果几个线程的程序中都引用全局量 errno，那么它们在运行中实际访问的就是同一个地址。为说明问题，我们且假定线程 T1 和 T2 属于同一进程，再来考察下述的假想情景：

1. T1 先通过 C 库函数 open() 进行系统调用，但是因为所给定的文件名实际上是个目录，所以内核返回出错代码 EISDIR。这个出错代码被写入了全局量 errno。
   
2. T1 发现 open() 的返回值为-1，因而需要以 errno 当时的值、即出错代码为参数调用 error()；但是，在 T1 还没有来得及从 errno 读出之前就发生了中断，而且导致线程调度，调度的结果是线程 T2 获得运行；
   
3. T2 通过 C 库函数 signal() 启动另一次系统调用，但是因为使用参数不当而出错，内核返回的出错代码为 EINVAL，表示参数无效。这个出错代码也被写入全局量 errno，于是 errno 的值变成了 EINVAL。
   
4. T2 从全局量 errno 读取出错代码，并依此进行相应的(正确)处理。但是 errno 的值仍保持为 EINVAL，此后 T2 没有再进行系统调用。
   
5. 一段时间之后，T1 又被调度运行，继续其原有的处理，即从 errno 读出、并以 errno 的值为参数调用 error()。但是，errno 的值原来是 EISDIR，而现在已变成 EINVAL。
   

由此可见，在多线程的环境下，对于某些应用，由多个线程共享一个同名的全局量是有问题的。
怎么解决呢？使用局部量当然是个办法，例如改成“if ((err=open(filename, mode)) < 0”，这似乎轻而易举地就解决了问题。可是，不幸的是，这就要求改变几乎所有 C 库函数的调用接口，而 C 库函数的调用接口早已成为标准。那么另外再定义一个新的 C 程序库怎么样？这也很成问题，新开发的软件固然可以改用新的界面，但是这么多已经存在的代码就都需要重新加以修改了。所以，这是不太现实的。
显然，就 errno 而言，比较好的解决方案是维持原有的代码和接口不变，但是让每个线程都有自己的 errno，或者说都有一个专用的 errno 副本。这就是“线程局部存储”，即 TLS。
于是，使用 TLS 就是自然的选择了。实际上，现在的 C 库函数不是把出错代码写入全局量 errno，而是通过一个函数 __errno_location() 获取一个地址，再把出错代码写入该地址，其意图就是让不同的线程使用不同的出错代码存储地点，这就是 TLS。而 errno，现在一般已经变成了一个宏定义：

#define errno (*__errno_location())

这样，原来代码中的“extern int errno;”就变成了“extern int (*__errno_location());”，这是一种挺巧妙的方案。

相比之下，Win32 API 的调用方式就不同了：

Status = NtOpenFile(...);
if(!NT_SUCCESS(Status))  {
    // error handle
}

当然，这里的 Status 是个局部变量，所以就不存在前述的问题了。这倒不是因为微软的人特别高明、早就预见到了可能发生的问题，而是因为时代不同，须知 Unix 的 C 库程序调用界面比 W32 API 的出现要早十多年。不过，尽管 Windows 对于系统调用的出错代码这个具体的数据没有线程局部存储的要求，这并不意味着在 Windows 系统中就不需要 TLS。事实上，Windows 也需要 TLS，这里不介绍它们了。

参考：https://wenku.baidu.com/view/2d442dd184254b35eefd344f.html

可重入函数更加严格。可重入函数一定是多线程安全函数，多线程安全函数不一定是可重入函数。

使用异步取消时，线程可以在任意时间取消，而不是非得遇到取消点才能被取消。

As a general principle, an asynchronously cancelable thread can’t allocate any resources or acquire any mutexes, semaphores, or locks. This precludes the use of a wide range of library functions, including most of the Pthreads functions. (SUSv3 makes exceptions for pthread_cancel(), pthread_setcancelstate(), and pthread_setcanceltype(), which are explicitly required to be async-cancel-safe; that is, an implementation must make them safe to call from a thread that is asynchronously cancelable.) In other words, there are few circumstances where asynchronous cancellation is useful. One such circumstance is canceling a thread that is in a compute-bound loop.
参考：The Linux Programming Interface, by Michael Kerrisk, Section 32.6 Asynchronous Cancelability.

一句话总结，只有 AC-Safe 的函数才能在可异步取消的线程中被调用。
假如一个可异步取消的线程正在调用一个不是 AC-Safe 的函数（如 malloc）时，其它线程向它发送了一个取消请求，它马上取消了，此时 malloc 函数还没有返回，这可能导致 malloc 函数内部的链表结构不一致。