目录
前言:
可重入函数
重谈进程等待和优化
前言:
在前文,我们已经介绍了信号产生,信号保存,信号处理的主题内容,本文作为信号处理的续篇,主要是介绍一些不那么重要的内容,第一个点是可重入函数,第二个点是在信号处理这里的进程等待。
那么话不多说,我们进入主题吧!
可重入函数
大家对于链表的增删查改已经是什么熟悉了吧?在Linux中,如果我们有一个链表,我们要对链表执行的操作是insert,那么从main函数进去之后,进行p->next这步的时候突然进行信号捕捉的话,这里肯定有人会有疑问的了,为什么会进行信号捕捉呢?
如果是这个进程的时间片到了呢?OS要调度其他的进程了,那么从用户态转到了内核态,此时进行信号的捕捉,所以捕捉到了信号,就又会插入节点,原本插入的节点是Node1的,这下多出来了一个Node2节点,可是我们甚至没有办法去调用node2节点,这造成的问题是什么呢?
造成的问题是十分严重的,即内存泄漏。
那么这种函数,会造成内存泄漏,或者说是涉及到了共享资源的,比如堆的开辟,比如全局变量,比如静态变量都是共享的,涉及到了以上共享资源的函数,就不满足可重入性。
那么我们应该如何实现具备可重入性的函数呢?
-
不使用全局或静态变量:因为全局或静态变量是共享的,多个线程同时访问可能会导致数据不一致。如果必须使用,则必须通过适当的同步机制(如互斥锁)来保护这些变量。
-
不调用不可重入的函数:如果一个函数调用了另一个不可重入的函数,那么它本身也会变成不可重入的。
-
不返回指向静态分配的内存的指针:因为这可能导致多个线程返回相同的指针,从而访问和修改相同的内存区域。
-
不使用任何依赖于特定线程环境的资源:例如,某些I/O操作(如标准输入/输出)可能依赖于特定的线程环境,如果它们不是线程安全的,那么调用这些操作的函数就不是可重入的。
其实方式很简单,我们只需要保证该函数没有使用共享资源即可,反例是stl里面的容器,几乎所有的容器都涉及到了堆上的开辟,比如扩容等操作,那么这些所有函数就不是可重入的。
这个点我们了解一下即可。
重谈进程等待和优化
有人好奇咯,这里明明介绍的是信号,和进程等待有什么关系呢?这里更厉害的其实还有涉及到了编译器的优化方面,并且编译器优化也分为了几个层次,我们先从进程等待入手。
我们先看一段代码:
int gflag = 0;void changedata(int signo)
{std::cout << "get a signo:" << signo << ", change gflag 0->1" << std::endl;gflag = 1;
}int main() // 没有任何代码对gflag进行修改!!!
{signal(2, changedata);while(!gflag); // while不要其他代码std::cout << "process quit normal" << std::endl;
}
可以发现发送2号信号之后,发现gflag确实是从0变成了1,不然while循环也是不能结束的。
好了,现在我们来谈谈编译器优化的问题,在C++里,连续的拷贝构造 + 构造,编译器是直接会优化成直接构造的,这个我们是十分清楚的。
那么,g++也是个编译器吧?它也会进行相应的优化,我们先man一下g++:
这一行代表的优化成都,默认的优化是O0,我们也可以在编译的时候修改优化程度,可是我们光是知道优化是没有用的,我们还需要介绍一下上面代码的硬件部分知识:
对于cpu来说,它执行的运算一般是分为逻辑运算和算数运算的,对于上面while里面的判断,执行的就是逻辑运算,不管是哪种运算,将值放到寄存器的时候,都是从物理内存里面放吧?
好,现在是cpu从物理内存里面得到对应的数据,当然这个过程是由OS来完成的,那么,每次都要从物理内存拿这个数据是不是有点麻烦OS了?所以编译器在这里如果开了优化,那么就不让cpu从物理内存里面获取gflag的值了,直接就让cpu从寄存器里面获取,也就是说,从运行函数开始,寄存器里面只有一个值,也就是第一次while判断里的gflag的值,那么也就代表,我们即便是修改了gflag的值,cpu也不知道,因为它只从寄存器里面读取:
将对应的makefile修改一下,然后我们试试:
发现的现象是,嘿!退不出去了,也就印证了编译器在这里的优化。
这种现象叫做没有保持内存的可见性。
那么我们如何保持内存的可见性呢?很简单,只需要用到一个关键字就可以了,volatile即可,这个在const部分我们也有使用该国,这里加一个关键字的事儿,所以就不过多演示了。
好了,现在我们来谈谈进程的等待。
我们知道,父进程一般是会等待子进程的吧?并且父进程要收集子进程的退出信息吧?
可是父进程怎么知道子进程什么时候退出呢?
实际上,子进程退出的时候,是会给父进程发送相关信号的,该信号是SIGCHLD:
该信号是对应的17号信号。
默认的行为其实是Ign,也就是忽略的意思。
void notice(int signo)
{std::cout << "get a signal: " << signo << " pid: " << getpid() << std::endl;pid_t rid = waitpid(-1, nullptr, 0);if (rid > 0){std::cout << "wait child success, rid: " << rid << std::endl;}else if (rid < 0){std::cout << "wait child success done " << std::endl;}
}
void DoOtherThing()
{std::cout << "DoOtherThing~" << std::endl;
}
int main()
{signal(SIGCHLD, notice);pid_t id = fork();if (id == 0){std::cout << "I am child process, pid: " << getpid() << std::endl;sleep(3);exit(1);}// fatherwhile (true){DoOtherThing();sleep(1);}return 0;
}
对于上面的代码是我们信号处理部分熟知的,我们通过这个代码,验证了子进程退出的时候的的确确会发送17号信号,可是我们在信号处理的时候也知道了,信号如果还没有处理完,是会自动屏蔽当前多出来的信号的,也就是我们创建多个子进程的事儿:
for (int i = 0; i < 10; i++){pid_t id = fork();if (id == 0){std::cout << "I am child process, pid: " << getpid() << std::endl;sleep(3);exit(1);}}
做了以上的修改之后,我们发现:
创建子进程之后,父进程等待子进程是一个一个等待的,这也验证了之前所说的,信号被屏蔽之后,会继续处理被屏蔽的信号。
那么,你说有没有进程是一直不退出的呢?如果创建了一个永远不退出的子进程怎么办?假设这里存在5个要退出的子进程,5个不知道是否退出的子进程,难道父进程要一个一个的问你是否要退出吗?
这是不现实的,如果父进程真的傻傻的去等待了,导致的结果就是两个进程永远退出不了,只能被系统回收。因为造成了阻塞,所以,我们可以将等待方式设置一下,变成非阻塞等待:
void notice(int signo)
{std::cout << "get a signal: " << signo << " pid: " << getpid() << std::endl;while (true){pid_t rid = waitpid(-1, nullptr, WNOHANG); // 阻塞啦!!--> 非阻塞方式if (rid > 0){std::cout << "wait child success, rid: " << rid << std::endl;}else if (rid < 0){std::cout << "wait child success done " << std::endl;break;}else{std::cout << "wait child success done " << std::endl;break;}}
}
并且,当我们对于17号信号设置成了忽略,子进程也不会出现僵尸问题了。
以上是对于信号处理的补充。
感谢阅读!