"可重入"和"线程安全"是两个概念 千万不要搞混了

 

大伙估计在多任务程序中使用printf打印一些信息是非常欢乐的一件事，运气不错的话偶尔错几个数据、乱几个码也不是什么大问题，倒霉点的可能就直接挂机、卡死了，那这些到底是什么原因导致的呢？   今天的这篇文章应该可以帮助你解决一大部分问题。  

01

两个概念

1、可重入函数   多任务系统中每个进程或线程都是由多种执行流并发运行的，当执行流同时进入同一个函数(大部分是由于中断)，而不会导致函数结果不确定或者错误，就可认为该函数是可重入的。  

  上图中的signal一般都是因为中断等原因产生的，在我们多任务系统中中断更是无时无刻的在随机发生着，一旦线程或者进程被中断转而去执行消息处理，而恰巧的是此时线程所执行的操作与信号处理相同，比如malloc，他们都共享同一个资源(全局堆空间)。   当信号处理返回到原来的执行流中却由于信号处理的改写而受影响，比如重入的问题导致malloc会分配相同的内存区域，或者其他的数据篡改，锁死等，这样该函数就是不可重入的。  2、线程安全   多个线程并发运行且执行相同的代码，而不会导致运行结果受影响，我们就认为是线程安全。  

  对于线程安全往往加个互斥锁就可以解决战斗，当然你如果没有使用全局变量、静态变量等等共享资源，那他们基本上是线程安全的。   其实从表面上看这两个概念并没有太大的差异，无非就是运行同一块代码，会不会导致不确定的结果。   3、VS  再仔细想想，其实这两个概念所关注的层面是不同的，可重入函数要求相同执行流执行不会受影响，而线程安全仅仅只是在线程这个层面上进行的要求。   所以可重入的要求比线程安全要更加严苛，可重入必定线程安全，而线程安全并不一定可重入，如下图是他们的关系:  

02

不可重入死锁 

下面我们来简单分析一下不可重入死锁的问题 :   

  上图我们为函数加了互斥lock(不考虑递归锁)，那么它就是线程安全的，然而刚把共享资源部分上锁，随机的中断信号处理发生了，转而执行信号处理函数，而在信号处理中也同样执行相同的Fuction代码，此时资源已经锁住，必须等待前面调用Fuction函数的线程释放，但此线程又在等待信号处理访问，最终死锁，凉凉！   当然你可以使用递归锁来进行处理，这在正常设计中是需要避免的，当时对于一些需要调用外部库的设计，只能选择递归锁等。  

03

可重入的识别

　　说实在对于很多玩RTOS的伙计，直接关中断、开中断的临界资源保护就基本告别了一部分不可重入问题，而这样的操作会影响多任务的并发执行，但是如果你只是加了几把锁，可能在程序中不重入的问题还是要注意一下。 这里不可重入问题不完全总结了几点：

　　1、标准IO函数都会使用到全局的数据结构，比如printf函数 ： 由于使用了全局标准输出stdout，所以线程不安全也就更不能重入了。

　　2、malloc和free ： 这两个函数都是在全局的堆空间上进行操作，如果有加锁那就是线程安全的，但是不可重入。

　　3、对于全局、静态的资源的访问都会导致线程不安全，比如一些函数使用的是静态缓存区等，你可以使用本地copy加临界区来进行保护，尽量使用局部变量。

　　4、调用不可重入或者线程不安全的函数也会继承对应特点。

责任编辑：xj

原文标题：同事"可重入"与"线程安全"老分不清，导致一堆bug！

文章出处：【微信公众号：嵌入式ARM】欢迎添加关注！文章转载请注明出处。