大伙估计在多任务程序中使用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】欢迎添加关注!文章转载请注明出处。
-
函数
+关注
关注
3文章
4274浏览量
62302 -
BUG
+关注
关注
0文章
155浏览量
15638 -
线程安全
+关注
关注
0文章
13浏览量
2453
原文标题:同事"可重入"与"线程安全"老分不清,导致一堆bug!
文章出处:【微信号:gh_c472c2199c88,微信公众号:嵌入式微处理器】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论