【APUE】Chapter12 Thread Control
今天看了APUE的Chapter12 Thread Control的内容，记录一下看书的心得与示例code。
这一章的内容是对Chapter11 Threads（见上一篇日志）的补充，大部分内容都是理论上的分析提点，大概就是告诉读者：你先知道pthread有这么个特性，如果将来遇到了可以去查查。
（一）Thread Limits
这里主要介绍了pthread_attr_t的属性变量，可以通过设置属性变来定制化threads的特性（P426）。
其中，一个重要的属性就是thread的stack size。代码示例如下：
#include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <string.h> void *thr_fun(void *arg) { puts("Thread is working."); pthread_exit((void *)0); } int main() { pthread_t tid; int err,i; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setstacksize(&attr, 1024*1024); for ( i=0;;++i ) { err = pthread_create(&tid, &attr, thr_fun, NULL); if( err ) { fprintf(stderr, "pthread_create():%s\n", strerror(err)); break; } } printf("i = %d\n",i); pthread_attr_destroy(&attr); exit(0); }
上述代码的功能是
（1）在main主线程中不断创建新的线程，用pthread_attr_t初始化每个线程的stack size为1024*1024B（单位是字节）
（2）每个线程的任务比较简答：就是puts一段儿字符串，然后就完事返回了
（3）虽然每个线程很快就完事儿了，但是产生的线程并没有被收尸，还占着当前进程的茅坑呢（还占用着产生它的进程的资源呢）。
运行结果如下：
代码运行的环境是一个centos server，大概当前线程能够负担的最大线程数是32750个1024*1024B的线程。
（二）Detach
如果我对上述的代码修改一下，如下：
pthread_attr_init(&attr); pthread_attr_setstacksize(&attr, 1024*1024); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
结果就不一样了：该程序会一直运行，除非人工强制结束进程。
或者像下面这样改：
err = pthread_create(&tid, &attr, thr_fun, NULL); if( err ) { fprintf(stderr, "pthread_create():%s\n", strerror(err)); break; } pthread_detach(tid);
结果也是程序一直运行，不停下来。
通过这个例子不仅可以理解pthread_attr_t的用法，同时对pthread_detach的含义有了进一步理解。
（1）在pthread_attr_setdetachstate中设定detach属性，相当于告诉操作系统，这个线程创建完就让他自生自灭了，运行完自己给自己清理了。
（2）phread_detach(tid)，相当于告诉操作系统，咱们主动为刚才创建的pthread_t为tid的线程收尸，把它清理干净了。
还有一种给线程收尸的方式是用pthread_join。但是敢用这种方式的前提是，调用pthread_join之前，线程没有被detach。看如下代码：
#include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <string.h> void *thr_fun(void *arg) { puts("Thread is working."); pthread_exit((void *)0); } int main() { pthread_t tid; int err,tret; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); err = pthread_create(&tid, &attr, thr_fun, NULL); if( err ) fprintf(stderr, "pthread_create():%s\n", strerror(err)); else printf("created\n"); err = pthread_join(tid, (void *)&tret); if( err ) fprintf(stderr, "pthread_create():%s\n", strerror(err)); else printf("joined\n"); pthread_attr_destroy(&attr); exit(0); }
上述代码运行结果如下：
从运行结果可以看到：线程被创建成功，并且执行了；但是由于线程在创建时候pthread_attr_t被设置成detach的了，于是pthread_join就对其失效了。
（三）Recursive Mutex
书上给了一段代码，但是仅供观看，不能run；为了能够运行出结果，我稍微做了一些修改。代码如下：
#include "apue.h" #include <pthread.h> #include <time.h> #include <sys/time.h> int makethread(void *(*fn)(void *), void *arg) { int err; pthread_t tid; pthread_attr_t attr; err = pthread_attr_init(&attr); if ( err!=0 ) return err; err = pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); if ( err==0 ) err = pthread_create(&tid, &attr, fn, arg); pthread_attr_destroy(&attr); return err; } struct to_info{ void (*to_fn)(void *); void *to_arg; struct timespec to_wait; }; #define SECTONSEC 1000000000 #define USECTONSEC 1000 void * timeout_helper(void *arg) { struct to_info *tip; tip = (struct to_info *)arg; clock_nanosleep(CLOCK_REALTIME, 0, &tip->to_wait, NULL); (*tip->to_fn)(tip->to_arg); free(arg); return 0; } void timeout(const struct timespec *when, void (*func)(void *), void *arg) { struct timespec now; struct to_info *tip; int err; clock_gettime(CLOCK_REALTIME, &now); if ( (when->tv_sec > now.tv_sec) || (when->tv_sec==now.tv_sec && when->tv_nsec > now.tv_nsec) ) { tip = malloc(sizeof(struct to_info)); if ( tip!=NULL ) { tip->to_fn = func; tip->to_arg = arg; tip->to_wait.tv_sec = when->tv_sec - now.tv_sec; if ( when->tv_nsec>=now.tv_nsec ) { tip->to_wait.tv_nsec = when->tv_nsec - now.tv_nsec; } else { tip->to_wait.tv_sec--; tip->to_wait.tv_nsec = SECTONSEC - now.tv_nsec + when->tv_nsec; } err = makethread(timeout_helper, (void *)tip); if (err==0) { printf("makethread return 0\n"); return; } else free(tip); } } (*func)(arg); } pthread_mutexattr_t attr; pthread_mutex_t mutex; void retry(void *arg) { printf("require mutex for the second time\n"); pthread_mutex_lock(&mutex); // perform retry FILE *fp; fp = fopen("./retry.dat","w+"); fputs("this a retry.",fp); fclose(fp); pthread_mutex_unlock(&mutex); } int main() { int err, condition, arg; struct timespec when; if ( (err = pthread_mutexattr_init(&attr)) != 0 ) err_exit(err, "pthread_mutexattr_init failed"); if ( (err = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)) != 0 ) err_exit(err, "can't set recursive type"); if ( (err = pthread_mutex_init(&mutex, &attr)) != 0 ) err_exit(err, "can't create recursive mutex"); condition = 1; pthread_mutex_lock(&mutex); if (condition) { printf("retry until timeout\n"); clock_gettime(CLOCK_REALTIME, &when); when.tv_sec += 10; timeout(&when, retry, (void *)((unsigned long)arg)); } pthread_mutex_unlock(&mutex); sleep(15); exit(0); }
上面的代码有虽然比较接近实际应用，但是对于阐述知识点来说有些冗余（感兴趣可以都看看），或者只看红字部分就足够了。
运行结果如下：
在当前路径下生成了retry.dat的文件，OK。
上面的结果很好分析：
（1）main中对mutex上锁，调用timeout并在其中由makethread产生了一个新的线程timeout_helper（延迟10秒调用retry函数），main对mutex解锁
（2）线程timeout_helper延迟10秒后调用retry函数（此时mutex早已在main中被解锁），对mutex上锁，执行操作，再对mutex解锁。
但如果将main函数中的两条语句调换顺序：
sleep(15); pthread_mutex_unlock(&mutex);
结果就不同了，这次不会输出retry.dat文件。
因为main线程先等待15秒，而这15秒一直占着mutex；同时，timeout_helper被mutex阻塞了，直到main线程执行unlock操作。
但是main一旦unlock，主进程就exit了；由于timeout_helper也是由这个进程产生了，因此没来得及执行呢就被一起收尸了。
这里容易产生个误区：makethread中有这么一句话：
err = pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
不是将timeout_helper设置成detached了么，与主线程脱钩了么？
是的，但是这个timeout_helper使用的资源依然离不开产生它的进程，因此在main中exit了，这个timeout_helper就被动收尸了。
下面，将如下的代码段屏蔽：
clock_gettime(CLOCK_REALTIME, &now); /* if ( (when->tv_sec > now.tv_sec) || (when->tv_sec==now.tv_sec && when->tv_nsec > now.tv_nsec) ) { tip = malloc(sizeof(struct to_info)); if ( tip!=NULL ) { tip->to_fn = func; tip->to_arg = arg; tip->to_wait.tv_sec = when->tv_sec - now.tv_sec; if ( when->tv_nsec>=now.tv_nsec ) { tip->to_wait.tv_nsec = when->tv_nsec - now.tv_nsec; } else { tip->to_wait.tv_sec--; tip->to_wait.tv_nsec = SECTONSEC - now.tv_nsec + when->tv_nsec; } err = makethread(timeout_helper, (void *)tip); if (err==0) { printf("makethread return 0\n"); return; } else free(tip); } } */ (*func)(arg);
大家稍微梳理下流程，就可以看到：在整个程序运行当众，只有一个main线程，并没有调用makethread产生新的线程。
因此有如下的结构：
main():
lock(mutex)
retry():
lock(mutex)
unlock(mutex)
unlock(mutex)
也就是说在同一个线程中对lock(mutex)锁了两次，如果不把mutex设定为recursive的，那就肯定死锁了；如果设定成了recursive的，就可以不死锁。
大家可以自己修改下代码测试一下，但是前提是在main的进程不能突然结束，否则任何操作就然并卵了。
=============================
还有个IBM的知识分享，可以看了
http://www.ibm.com/developerworks/cn/linux/l-cn-mthreadps/
12.8 Threads and Signals
作者提醒大家，“信号+进程”本身就已经比较复杂了，如果再跟多线程搅和在一起就更加作死了。
有几个基本的outline：
（1）每个线程都有各自的signal mask（可以设定当前线程屏蔽哪些信号）
（2）但是signal处理函数，在进程内是各个线程共享的（某个signal handler改了 其余的都受到影响）
（3）signal一般是发给单独线程的；如果是hardware fault相关的内容，哪个线程引起的就发给哪个线程
（4）给线程设置signal mask需要用pthread_sigmask函数，这个函数与sigprocmask几乎相同，区别在于pthread_sigmask如果执行错误，会返回错误码；而sigprocmask执行错误会重置errno的值，并且返回-1
两个重要的函数：
1. pthread_sigmask(int how, const sigset_t *restrict set, sigset_t *restrict oset);
三个参数的具体含义与sigprocmask类似，不再追溯。
2. sigwait(const sigset_t *restrict set, int *restrict signop);
set : 表示要等哪些signal
signop: 用于记录等来的是哪个signal (因为再set中可能等好几个signal，其中任何一个signal的到来都可以让sigwai停止阻塞，因此需要记录到底是哪个signal来的)
作者还特意强调，为了避免“erroneous behavior”，在调用sigwait之前，先要把需要等待的信号block了；在调用sigwait之后，会自动将set中的signal都unblock，然后再等signal到来
这亮个函数的好处在于，可以单独开一个线程，异步处理特定的信号。具体的做法如下：
（1）在不需要接收到特定信号的线程中，用pthread_sigmask在当前线程中屏蔽这些信号
（2）然后在用一个线程专门等着处理这个信号，sigwait就派上用场了
看一个例子：
#include <pthread.h>
#include "apue.h"
int quitflay; /*set nonzero by thread*/
sigset_t mask;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t waitloc = PTHREAD_COND_INITIALIZER;
void * thr_fn(void *arg)
{
int err, signo;
for(; ;)
{
err = sigwait(&mask, &signo); /*mask是要等着的信号集合 signo存放等来的信号*/
if (err!=0)
err_exit(err, "sigwait failed");
switch (signo)
{
case SIGINT:
printf("\ninterrupt\n");
break;
case SIGQUIT:
pthread_mutex_lock(&lock);
quitflay = 1;
pthread_mutex_unlock(&lock);
pthread_cond_signal(&waitloc);
return 0;
default:
printf("unexpected signal %d\n", signo);
exit(1);
}
}
}
int main()
{
int err;
sigset_t oldmask;
pthread_t tid;
sigemptyset(&mask);
sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGQUIT);
pthread_sigmask(SIG_BLOCK, &mask, &oldmask);
pthread_create(&tid, NULL, thr_fn, 0);
pthread_mutex_lock(&lock);
while (quitflay==0)
pthread_cond_wait(&waitloc, &lock);
pthread_mutex_unlock(&lock);
quitflay = 0;
sigprocmask(SIG_SETMASK, &oldmask, NULL);
exit(0);
}
代码执行结果：
分析如下：
（1）在main的主线程中先堵住SIGINT和SIGQUIT信号
（2）堵完了之后，再用pthread_create创建新的线程，实际上就是注册了一个信号处理的线程
（3）这个新线程的signal mask继承了创建其的main线程中的signal mask（留到最后再说这个）
（3）判断quitflag的值来判断是否往下执行（这里用“条件变量+锁”的形式来保持对全局变量mash读写的同步动作）
（4）那么，有没有可能出现信号空等待的情况呢？假象一种情况：如果main函数中，pthread_create和while之间的time window中来了一个SIGINT或者SIGQUIT信号，会怎么处理？其实也没事，如果来的是SIGINT，没关系，正常进入while循环等着；如果来但是SIGQUIT，此时quitflag已经被置为1了，while循环不会执行等待。所以，经过分析，这种信号处理模式是等待安全的。
总结一下上述的代码，pthread_sigmask屏蔽的目的是让不该接收到该信号的线程收不到；而某个线程中的sigwait起到的作用是“瞬间unblock开set中的那些信号 → 接收信号，保存到signo里面 → 恢复信号mask → 处理signo这个信号”。而在这期间，只有sigwait的时候是瞬间unblock的，其余的时间都是继承main中对信号的屏蔽的。
对上述代码修改如下：
#include <pthread.h>
#include "apue.h"
int quitflay; /*set nonzero by thread*/
sigset_t mask;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t waitloc = PTHREAD_COND_INITIALIZER;
void * thr_fn(void *arg)
{
int err, signo;
sigset_t curr;
sigprocmask(SIG_BLOCK, NULL, &curr);
if ( sigismember(&curr, SIGINT) )
printf("blocking SIGINT\n");
if ( sigismember(&curr, SIGQUIT) )
printf("blocking SIGQUIT\n");
for(; ;)
{
err = sigwait(&mask, &signo); /*mask是要等着的信号集合 signo存放等来的信号*/
if ( sigismember(&curr, SIGINT) )
printf("blocking SIGINT\n");
if ( sigismember(&curr, SIGQUIT) )
printf("blocking SIGQUIT\n");
if (err!=0)
err_exit(err, "sigwait failed");
switch (signo)
{
case SIGINT:
printf("\ninterrupt\n");
break;
case SIGQUIT:
pthread_mutex_lock(&lock);
quitflay = 1;
pthread_mutex_unlock(&lock);
pthread_cond_signal(&waitloc);
return 0;
default:
printf("unexpected signal %d\n", signo);
exit(1);
}
}
}
int main()
{
int err;
sigset_t oldmask;
pthread_t tid;
sigemptyset(&mask);
sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGQUIT);
pthread_sigmask(SIG_BLOCK, &mask, &oldmask);
//sigprocmask(SIG_BLOCK, &mask, &oldmask);
pthread_create(&tid, NULL, thr_fn, 0);
pthread_mutex_lock(&lock);
while (quitflay==0)
pthread_cond_wait(&waitloc, &lock);
pthread_mutex_unlock(&lock);
quitflay = 0;
sigprocmask(SIG_SETMASK, &oldmask, NULL);
exit(0);
}
再次运行结果如下：
上述代码的修改就是在信号处理线程中sigwait前后均获取当前线程是否阻塞某些信号。可以看到，在信号处理线程中sigwait前后都屏蔽了信号，但是还能够处理这些信号；也就是说，只有sigwait这个函数执行的瞬间，SIGINT和SIGQUIT是unblock的，之前和之后都与main中信号mask相同。
还有一点需要总结，不是说各个线程间的signal mask可以是独立的么？下面写一个例子，直观帮助理解，代码如下：
#include <pthread.h>
#include "apue.h"
int quitflay; /*set nonzero by thread*/
sigset_t mask;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t waitloc = PTHREAD_COND_INITIALIZER;
void signal_check()
{
sigset_t curr;
sigprocmask(SIG_BLOCK, NULL, &curr);
if ( sigismember(&curr, SIGINT) )
printf("blocking SIGINT\n");
if ( sigismember(&curr, SIGQUIT) )
printf("blocking SIGQUIT\n");
if ( sigismember(&curr, SIGUSR1) )
printf("blocking SIGUSR1\n");
}
void * thr_fn(void *arg)
{
int err, signo;
printf("befor setting mask in signal handling thread...\n");
signal_check();
sigset_t extra;
sigaddset(&extra, SIGUSR1);
sigprocmask(SIG_BLOCK, &extra, NULL);
printf("after setting mask in signal handling thread...\n");
signal_check();
for(; ;)
{
err = sigwait(&mask, &signo); /*mask是要等着的信号集合 signo存放等来的信号*/
if (err!=0)
err_exit(err, "sigwait failed");
switch (signo)
{
case SIGINT:
printf("\ninterrupt\n");
break;
case SIGQUIT:
pthread_mutex_lock(&lock);
quitflay = 1;
pthread_mutex_unlock(&lock);
pthread_cond_signal(&waitloc);
return 0;
default:
printf("unexpected signal %d\n", signo);
exit(1);
}
}
}
int main()
{
int err;
sigset_t oldmask;
pthread_t tid;
sigemptyset(&mask);
sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGQUIT);
pthread_sigmask(SIG_BLOCK, &mask, &oldmask);
//sigprocmask(SIG_BLOCK, &mask, &oldmask);
pthread_create(&tid, NULL, thr_fn, 0);
sleep(2);
printf("check signal in main after pthread_create...\n");
signal_check();
pthread_mutex_lock(&lock);
while (quitflay==0)
pthread_cond_wait(&waitloc, &lock);
pthread_mutex_unlock(&lock);
quitflay = 0;
sigprocmask(SIG_SETMASK, &oldmask, NULL);
exit(0);
}
运行结果如下：
上述代码为了验证各个线程间signal mask的独立性，专门在thr_fn中多屏蔽了一个SIGUSR1，看看main线程是否会收到影响。结果是main线程的signal mask并没有收到影响。再总结一下：
（1）从main中pthread_create()这地方开始，产生了一个新的线程，同时新的线程继承了main线程中的signal mask；这也就是为什么thr_fn上来就已经把SIGINT和SIGQUIT给屏蔽了
（2）紧接着，在thr_fn中再把SIGUSR1给屏蔽了，马上thr_fn中就体现出来屏蔽SIGUSR1了；随后再检查main线程中的屏蔽信号，还是SIGINT和SIGQUIT两个，thr_fn中屏蔽的SIGUSR1并没有影响到main线程中对SIGUSR1的处理方式。
结合以上两点，可以直观理解每个线程的signal mask都是独立的。
还想继续探究，当pthread_create()执行时，有关信号处理的方面到底发生了什么？查阅了如下的资料：
更具体的参见：http://man7.org/linux/man-pages/man3/pthread_create.3.html
12.9 Threads and fork
这里的核心在于如何在多线程+多进程环境下处理锁的问题。
首先需要回顾一下8.3节的fork函数，尤其是copy-on-write的优化的fork实现方法：
（1）fork出一个child process后，parent process和child process的地址空间并非完全独立
（2）为了提高效率，如果parent process中的变量虽然copy给了child process，但只是对这个变量有“读"的操作是不会在child process中给这个变量再内存中开辟一个独立的新的地址的；只有对这个变量有“写”的操作了，这时候才会给这个变量在child process中完全独立开辟内存空间
以上是copy-on-write的fork的背景知识。
再说一下多线程状态下的fork：
（1）fork之后，copy到child process中只有一个线程，parent process中哪个线程fork的，就copy那个线程
（2）如果copy到child process中的那个线程中，有被lock住的mutex，则这种lock的状态也会被child process所继承
这里的问题就在于，很可能真正lock住mutex的那个线程并没有被copy到child process中，这样就容易出现死锁的问题（因为child process中没有那个对mutex实际锁住的线程，并且mutex是独立的，也就永远不会获得那个线程中解锁的操作了）。
书上给出的是一种比较暴力的方法：在fork的时候，把各种需要打开的锁都unlock了。
为了解决上述的问题，给出了相关的系统函数：
pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void));
这个函数就是一个注册用的函数，在执行fork的时候被触发。几个参数的意义如下：
（1）prepare : 在fork出child之前用；获取所有的locks
（2）parent : 在fork出child之后，但fork return之前用；在父进程中解锁
（3）child : 在fork出child之后，但fork return之前用；在子进程中解锁
先看一个例子：
#include <pthread.h>
#include "apue.h"
pthread_mutex_t lock1 = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t lock2 = PTHREAD_MUTEX_INITIALIZER;
void prepare(void)
{
int err;
printf("preparing locks...\n");
/*养成这种容错编程的习惯 否则出错了都不知道是哪出的错误*/
if ((err=pthread_mutex_lock(&lock1))!=0) {
err_cont(err, "can't lock lock1 in prepare handler");
}
if ((err=pthread_mutex_lock(&lock2))!=0) {
err_cont(err, "can't lock lock2 in prepare handler");
}
}
void parent(void)
{
int err;
printf("parent unlocking locks...\n");
if ((err=pthread_mutex_unlock(&lock1))!=0) {
err_cont(err, "can't unlock lock1 in parent handler");
}
if ((err=pthread_mutex_unlock(&lock2))!=0) {
err_cont(err, "can't unlock lock2 in parent handler");
}
}
void child(void)
{
int err;
printf("child unlocking locks...\n");
if ((err=pthread_mutex_unlock(&lock1))!=0) {
err_cont(err, "can't unlock lock1 in child handler");
}
if ((err=pthread_mutex_unlock(&lock2))!=0) {
err_cont(err, "can't unlock lock2 in child handler");
}
}
void * thr_fn(void *arg)
{
printf("thread started...\n");
pause();
return 0;
}
int main()
{
int err;
pid_t pid;
pthread_t tid;
if ((err=pthread_atfork(prepare, parent, child))!=0) {
err_exit(err, "can't install fork handlers");
}
if ((err=pthread_create(&tid, NULL, thr_fn, 0))!=0) {
err_exit(err, "can't create thread");
}
sleep(2);
printf("parent about to fork...\n");
if ((pid=fork())<0) {
err_quit("fork failed");
}
else if (pid==0) {
printf("child returned from fork\n");
}
else {
printf("parent returned from fork\n");
}
exit(0);
}
程序运行结果如下：
分析如下：
（1）prepare最先执行，而且是在fork出child之前执行的。为什么要有这么一个prepare？因为，如果敢在多线程条件下用fork，就必须保证fork中涉及的各个mutex的状态都得是可控的（即不能被其他的线程lock住）。这也就解决了之前提到的一个问题，“如果copy到child process的线程中有mutex被原来父进程中的某个线程锁住了怎么办？”；因为，如果一旦prepare对所有相关的mutex都获得控制权了，自然就可以避免上面的问题了。
（2）parent handler在fork出child之后，但是fork return之前执行；child handler在fork出child之后，但是fork return之前执行。这里还有一个问题：为什么给人感觉prepare加锁只有一次，但是parent handler和child handler却解锁了两次？这个问题书上说的很清楚，这是由于copy-on-write的fork实现策略给人造成的错觉。的确，在prepare获得mutex控制权的时候，lock1和lock2在内存中只有一份的；但是一旦parent handler或child handler对lock1和lock2有写操作了，马上就会先给child process在内存中独立分配出一套新的lock1和lock2变量。因此，parent handler中的解锁是针对原来的lock1和lock2，而child handler中的解锁是针对新的lock1和lock2。这样的操作是没有问题的。
书上还给出了多次调用pthread_atfork的分析，但这部分没有例子。
我的理解就是，这是针对locking hierarchy的操作，强调多个pthread_atfork的注册顺序和执行顺序。
背景：A模块调用B模块，两个模块都有各自的锁（A中有lock1 lock2，B中有lock3 lock4）；现在要fork，该怎么处理？
方法：这种情况下，A的锁再外面，B的锁在里面；因此针对B的pthread_atfork一定要在A前面注册
执行顺序：parent handler和child handler按照注册顺序去调用；而prepare按照与注册相反的顺序去调用
这里需要理解两个问题：
（1）为什么prepare的执行顺序要与注册顺序相反（注意，这里B的pthread_atfork是先于A的pthread_atfork的）？原因就是，为了在获得锁的控制权的时候，依然保持原来的hierarchy；如果prepare获得了B中的锁，此时如果父进程中的A模块正等着B中的锁才能往下进行呢？于是就憋住了，形成死锁了。反之，如果能够获得A的锁，就从源头保住了不会出现A等着B的锁才能往下进行的死锁情况。这个内容，后面最好写一个例子。
（2）为什么parent handler和child handler的执行顺序与注册顺序相同了呢？我理解就是，加锁顺序是lock1 lock2 lock3 lokc4，那么解锁的顺序就应该是lock4 lock3 lock2 lock1。由于B中的pthread_atfork是先于A中的pthread_atfork注册的，所以parent handler和child handler就是按照注册的顺序执行，就符合解锁顺序了，不会造成死锁问题。
完毕。
