如果不加互斥锁，优先级高的任务，会抢占串口并发送数据，则有可能会出现发送数据“乱码”的情况。
今天，我们就来讲一讲在RTOS开发中互斥锁一个常见的问题。
01
什么是Mutex互斥锁？
就如上面说的，一个串口，被两个任务抢占，如果不加锁，则会出现两个任务交叉发送数据，即“乱码”。
但是，如果加了互斥锁，则会等待其他任务发送完成之后才继续发送，保证了数据的完整（而不是乱码）。
02
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次加锁、解锁，而且“环环相扣”。
03
Mutex互斥锁问题
优先级顺序就是：任务1 > 任务2 > 任务3（数字越小代表任务优先级越高）。
假设：任务1和任务2处于等待事件状态，也就是处于阻塞状态， task 3 处于运行状态。
当任务3在“加锁处理事情”的时候，任务2抢占了任务3（任务2挂起时间到了），此时任务3挂起，任务2处于运行状态；
如果任务2在“互斥锁1加锁”之后，任务1抢占了任务2，此时，任务1处于运行状态；
这个时候，你发现问题了没有？
任务1在执行“OSMutex1_Pend();”会等待“互斥锁1解锁”，如果其他方式没有对“互斥锁1解锁”，则会出现“死锁”的情况。
04
解决办法
比如，对任务2加锁方式进行改善：
void task2(){/*do something*/OSMutex1_Pend(); //互斥锁1加锁/*do something*/OSMutex1_Post(); //互斥锁1解锁OSMutex2_Pend(); //互斥锁2加锁/*do something*/OSMutex2_Post(); //互斥锁1解锁}
void task3(){/*do something*/OSMutex1_Pend(); //互斥锁1加锁OSMutex2_Pend(); //互斥锁2加锁/*加锁处理事情*/OSMutex2_Post(); //互斥锁2解锁OSMutex1_Post(); //互斥锁1解锁}
出问题的原因，当一个任务获得了临界区资源的锁，在没有释放这个锁的前提下又去获得另外一块临界区资源，这个时候就要引起足够的注意了，设计成败在于你是否彻底理解了之前的问题。
但归根到底，这样的问题还是要求用户在设计阶段去避免，一个系统不可能是万能的，正确的设计才是最重要的。
END
→点关注，不迷路←
