查看原文
其他

RTOS 任务间Mutex互斥一个常见的问题

strongerHuang 嵌入式专栏 2022-05-20

关注+星标公众,不错过精彩内容

作者 | strongerHuang

微信公众号 | 嵌入式专栏


在基于RTOS开发项目时,通常都会遇到互斥的情况,比如:几个任务都要使用一个UART串口进行发送数据。


如果不加互斥锁,优先级高的任务,会抢占串口并发送数据,则有可能会出现发送数据“乱码”的情况。


今天就说说在RTOS开发中,互斥锁一个常见的问题。


嵌入式专栏

1

什么是Mutex互斥锁?

学习过RTOS的读者应该对互斥不陌生,互斥锁就是为了避免任务之间互相抢占某种资源而设计的一种“锁”。


就如上面说的,一个串口,被两个任务抢占,如果不加锁,则会出现两个任务交叉发送数据,即“乱码”;


但是,如果加了互斥锁,则会等待其他任务发送完成之后才继续发送,保证了数据的完整(而不是乱码);


嵌入式专栏

2

Mutex互斥锁例子

这里以三个任务、两个互斥锁为例,代码如下:

void task1(){ /*do something*/
OSMutex1_Pend(); //互斥锁1加锁 /*加锁处理事情*/ OSMutex1_Post(); //互斥锁1解锁}
void task2(){ /*do something*/  OSMutex1_Pend(); //互斥锁1加锁 OSMutex2_Pend(); //互斥锁2加锁 /*加锁处理事情*/ OSMutex2_Post(); //互斥锁2解锁 OSMutex1_Post(); //互斥锁1解锁}
void task3(){ /*do something*/
OSMutex2_Pend(); //互斥锁2加锁  /*加锁处理事情*/ OSMutex2_Post(); //互斥锁1解锁}


这样设计,大家看出问题了吗?


老司机应该看出来了,新手可能摸不着头脑。


在任务2中,进行了2次加锁、解锁,而且“环环相扣”。


嵌入式专栏

3

Mutex互斥锁问题

假如任务1、 任务2、 任务3优先级分别为:1、 2、 3。


优先级顺序就是:任务1 > 任务2 > 任务3(数字越小代表任务优先级越高)。


假设:任务1和任务2处于等待事件状态,也就是处于阻塞状态, task 3 处于运行状态


当任务3在“加锁处理事情”的时候,任务2抢占了任务3(任务2挂起时间到了),此时任务3挂起,任务2处于运行状态


如果任务2在“互斥锁1加锁”之后,任务1抢占了任务2,此时,任务1处于运行状态


这个时候,你发现问题了没有?

任务1在执行“OSMutex1_Pend();”会等待“互斥锁1解锁”,如果其他方式没有对“互斥锁1解锁”,则会出现“死锁”的情况。


分享一张图片,你就会明白什么是死锁了:


嵌入式专栏

4

解决办法

比如对任务2加锁方式进行改善:

void task2(){ /*do something*/ OSMutex1_Pend(); //互斥锁1加锁 /*do something*/ OSMutex1_Post(); //互斥锁1解锁
OSMutex2_Pend(); //互斥锁2加锁 /*do something*/ OSMutex2_Post(); //互斥锁1解锁}


或者对低优先级的任务3加锁方式进行改善:

void task3(){ /*do something*/
OSMutex1_Pend(); //互斥锁1加锁 OSMutex2_Pend(); //互斥锁2加锁 /*加锁处理事情*/ OSMutex2_Post(); //互斥锁2解锁 OSMutex1_Post(); //互斥锁1解锁}


出问题的原因, 当一个任务获得了临界区资源的锁,在没有释放这个锁的前提下又去获得另外一块临界区资源,这个时候就要引起足够的注意了,设计成败在于你是否彻底理解了之前的问题。

但是,归根到底这样的问题还是要求用户在设计阶段去避免,一个系统不可能是万能的,正确的设计才是最重要的。
------------ END ------------


后台回复『RTOS』『嵌入式软件设计与开发』阅读更多相关文章。


欢迎关注我的公众号回复“加群”按规则加入技术交流群,回复“1024”查看更多内容。

欢迎关注我的视频号:


点击“阅读原文”查看更多分享,欢迎点分享、收藏、点赞、在看。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存