RTOS 任务间互斥的难题

作者 | strongerHuang

微信公众号 | 嵌入式专栏

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

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

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

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

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

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

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

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次加锁、解锁，而且“环环相扣”。

假如任务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解锁”，则会出现“死锁”的情况。

比如对任务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解锁}

点击“阅读原文”查看更多分享。