＜Linux＞可重入函数 volatile关键字以及SICHLD信号

一、可重入函数

（一）引入

（二）可重入函数的判断

二、volatile关键字

（一）概念

（二）关于编译器的优化的简单讨论

三、SIGCHLD信号

一、可重入函数

（一）引入

我们来先看一个例子来帮助我们理解什么是可重入函数：

假设我们现在要对一个链表进行头插，在执行到第10行代码时，突然进程的时间片到了，进程被切换了，一会等进程再度切换回来时，当前进程要处理信号，而信号处理函数是sighandler，而sighandler里面也进行了头插，等进程从内核态返回到用户态时，继续执行第11行的代码，这时我们再观察链表的结构会发现链表中节点 node1 还未完成插入时，node2 也进行了头插，最终导致节点 node2 丢失，造成 内存泄漏。

node_t node1, node2, *head;
int main()
{...insert(&node1);...
}void insert(node_t*p)
{p->next = head;head = p;
}void sighandler(int signo)
{insert(&node2);
}

导致 内存泄漏 的罪魁祸首：对于 node1 和 node2 来说，操作的 单链表 是同一个，同时进行并发访问（重入）会出现问题的，因为此时的单链表是 临界资源。

由这个问题衍生出了一种函数分类的方式：

如果一个函数同时被多个执行流进入所产生的结果没有问题，该函数被称为可重入函数。
如果一个函数同时被多个执行流进入所产生的结果有问题，该函数被称为不可重入函数。

可重入函数主要用于多任务环境中，一个可重入的函数通常来说就是可以被中断的函数，也就是说，可以在这个函数执行的任何时刻中断它，转入OS调度下去执行另外一段代码，而返回控制时不会出现什么错误；
不可重入的函数由于使用了一些系统资源，比如全局变量区，中断向量表等，所以它如果被中断的话，可能会出现问题，这类函数是不能运行在多任务环境下的。

（二）可重入函数的判断

如果一个函数符合以下条件之一则是不可重入的:

函数体内使用了静态（static）的数据结构或者变量；
调用了malloc或free,因为malloc也是用全局链表来管理堆的。
调用了标准I/O库函数。标准I/O库的很多实现都以不可重入的方式使用全局数据结构。

二、volatile关键字

（一）概念

volatile是C语言的一个关键字，该关键字的作用是保证内存数据的可见性。

比如在下面这个例子中

借助全局变量 falg 设计一个死循环的场景，在此之前将 2 号信号进行自定义动作捕捉，具体动作为：将 flag 改为 1，可以终止 main 函数中的循环体

#include <stdio.h>
#include <signal.h>int flag = 0;   // 一开始为假void handler(int signo)
{printf("%d号信号已经成功发出了\n", signo);flag = 1;
}int main()
{signal(2, handler);while(!flag);   // 故意不写 while 的代码块 { }printf("进程已退出\n");return 0;
}

初步结果符合预期，2 号信号发出后，循环结束，程序正常退出

这段代码能符合我们预期般的正确运行是因为 当前编译器默认的优化级别很低，没有出现意外情况。

通过指令查询 gcc 优化级别的相关信息：

man gcc

其中数字越大，优化级别越高，理论上编译出来的程序性能会更好。

事实真的如此吗？

让我们重新编译上面的程序，并指定优化级别为 O1

gcc mySignal mySignal.c -O1

此时得到了不一样的结果：2 号信号发出后，对于 falg 变量的修改似乎失效了

将优化级别设为更高是一样的结果，如果设为 O0 则会符合预期般的运行，说明我们当前的编译器默认的优化级别是 O0

查看编译器的版本：

gcc --version

那么我们这段代码哪个地方被优化了呢？

答案是 while 循环判断

首先要明白：

对于程序中的数据，需要先被 load 到 CPU 中的 寄存器 中
判断语句所需要的数据（比如 flag），在进行判断时，是从 寄存器 中拿取并判断
根据判断的结果，判断代码的下一步该如何执行（通过 PC 指针指向具体的代码执行语句）

所以程序在优化级别为 O0 或更低时，是这样执行的：

（二）关于编译器的优化的简单讨论

上面的代码如果我们不开启优化，就算不加上volatile关键字也是能正常运行的，可见编译器的优化不是越高越好。

如何理解编译器的优化?

编译器的本质是将代码翻译成01的二进制序列，所以编译器的优化是在你编写的代码上动手脚，也就是说编译器的优化其实改变了一些最终翻译成01二进制以后的执行逻辑。

三、SIGCHLD信号

在 进程控制 学习时期，我们明白了一个事实：父进程必须等待子进程退出并回收，并为其 “收尸”，避免变成 “僵尸进程” 占用系统资源、造成内存泄漏。

那么 父进程是如何知道子进程退出了呢？

在之前的场景中，父进程要么就是设置为 阻塞式专心等待，要么就是 设置为 WNOHANG 非阻塞式等待，这两种方法都需要 父进程 主动去检测 子进程 的状态。

如今学习了 进程信号 相关知识后，可以思考一下：子进程真的是安安静静的退出的吗？

答案当然不是，子进程在退出后，会给父进程发送 SIGCHLD 信号。

可以通过 SIGCHLD 信号 通知 父进程，子进程 要退出了，这样可以解放 父进程，不必再去 主动检测 ，而是 子进程 要退出的时候才通知其来 “收尸”：

SIGCHLD 信号比较特殊，该信号的默认处理动作是忽略。

首先通过程序证明一下子进程会发出 SIGCHLD 信号，通过自定义捕捉，打印相关信息：

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>void handler(int signo)
{printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo);
}int main()
{signal(SIGCHLD, handler);pid_t id = fork();if(id == 0){int n = 5;while(n)printf("子进程剩余生存时间: %d秒 [pid: %d  ppid: %d]\n", n--, getpid(), getppid());// 子进程退出exit(-1);}waitpid(id, NULL, 0);return 0;
}

因此可以证明 SIGCHLD 是被子进程真实发出的，当然，我们可以让父进程自定义捕捉动作为 回收子进程，让父进程不再主动检测子进程的状态，这样父进程只需专心处理自己的工作，不必关心子进程了，子进程终止时会通知父进程，父进程在信号处理函数中调用wait或waitpid清理子进程即可：

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>pid_t id;   // 将子进程的id设为全局变量，方便对比void handler(int signo)
{printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo);// 这里的 -1 表示父进程等待时，只要是已经退出了的子进程，都可以进行回收pid_t ret = waitpid(-1, NULL, 0);if(ret > 0)printf("父进程: %d 已经成功回收了 %d 号进程，之前的子进程是 %d\n", getpid(), ret, id);
}int main()
{signal(SIGCHLD, handler);id = fork();if(id == 0){int n = 5;while(n){printf("子进程剩余生存时间: %d秒 [pid: %d  ppid: %d]\n", n--, getpid(), getppid());sleep(1);}// 子进程退出exit(-1);}// 父进程很忙的话，可以去做自己的事while(1){// TODOprintf("父进程正在忙...\n");sleep(1);}return 0;
}

父进程和子进程各忙各的，子进程退出后会发信号通知父进程，并且能做到正确回收：

那么这种方法就一定对吗？

答案是不一定，在只有一个子进程的场景中，这个代码没问题，但如果是涉及多个子进程回收时，这个代码就有问题了

根本原因：SIGCHLD 也是一个信号啊，它可能也会在 block 表和 pending 表中被置为 1，当多个子进程同时向父进程发出信号时，父进程只能先回收最快发出信号的子进程，并将随后发出信号的子进程 SIGCHLD 信号保存在 blcok 表中，除此之外，其他的子进程信号就丢失了，父进程处理完这两个信号后，就认为没有信号需要处理了，这就造成了内存泄漏。

解决方案：自定义捕捉函数中，采取 while 循环式回收，有很多进程都需要回收没问题，排好队一个个来就好了，这样就可以确保多个子进程同时发出 SIGCHLD 信号时，可以做到一一回收。

细节：多个子进程运行时，可能有的退了，有的没退，这会导致退了的子进程发出信号后，触发自定义捕捉函数中的循环等待机制，回收完已经退出了的子进程后，会阻塞式的等待还没有退出的子进程，如果子进程一直不退，就会一直被阻塞，所以我们需要把进程回收设为 WNOHANG 非阻塞式等待。

void handler(int signo)
{printf("进程 %d 捕捉到了 %d 号信号\n", getpid(), signo);// 这里的 -1 表示父进程等待时，只要是已经退出了的子进程，都可以进行回收while (1){pid_t ret = waitpid(-1, NULL, WNOHANG);if (ret > 0)printf("父进程: %d 已经成功回收了 %d 号进程\n", getpid(), ret);elsebreak;}printf("子进程回收成功\n");
}int main()
{signal(SIGCHLD, handler);// 创建10个子进程int n = 10;while (n--){pid_t id = fork();if (id == 0){int n = 5;while (n){printf("子进程剩余生存时间: %d秒 [pid: %d  ppid: %d]\n", n--, getpid(), getppid());sleep(1);}// 子进程退出exit(-1);}}// 父进程很忙的话，可以去做自己的事while (1){// TODOprintf("父进程正在忙...\n");sleep(1);}return 0;
}

分为几批次地把所有子进程都成功回收了：

其实还有一种更加优雅的子进程回收方案：

由于 UNIX 历史原因，要想子进程不变成 僵尸进程，可以把 SIGCHLD 的处理动作设为 SIG_IGN 忽略，这里的忽略是个特例，只是父进程不对其进行处理，但只要设置之后，子进程在退出时，由操作系统对其负责，自动清理资源并进行回收，不会产生僵尸进程。

也就是说，直接在父进程中使用 signal(SIGCHLD, SIG_IGN) 就可以优雅的解决 子进程回收问题，父进程既不用等待，也不需要对信号做出处理。

原理：在设置 SIGCHLD 信号的处理动作为忽略后，父进程的 PCB 中有关僵尸进程处理的标记位会被修改，子进程继承父进程的特性，子进程在退出时，操作系统检测到此标记位发生了改变，会直接把该子进程进行释放。