关于RT-Thread调度器锁

版权声明：本文为博主原创文章，转载请注明出处！ https://blog.csdn.net/qq_20553613/article/details/81294726

1.前言
  RT-Thread系统开发，业务应用使用到了RT-Thread的调度器锁，因为使用不慎导致走了一部分弯路。致命的错误是，未有考虑到逻辑的执行与非执行后果，线程上锁后，逻辑条件未满足调度锁未能释放，从而导致其他线程未能获得CPU资源，出现是系统“假死”的现象。由于逻辑条件比较难重现，任务线程也及中断条件也不少，查找问题花费一部分时间。当然，最后还是发现致命的基础问题，就是调度器锁未能及时释放。作个总结。

2.RTT调度器锁
  调度器锁，是用于线程同步的一种方式，RT-Thread提供的调度器锁在使用时比较简单，只有上锁（rt_enter_critical）和解锁（rt_exit_critical）两个接口，但结合业务逻辑来说，则需注意，比如上述基本问题。调度器锁与中断锁类似，上锁后只有解锁后其他线程才能获取CPU资源执行；不同的是，调度器锁上锁后如有中断进入，系统仍然可以响应中断，中断锁则是屏蔽了包括中断在内的所有任务响应。根据调度锁特点，在业务应用层使用到调度锁时，需要考虑上锁后处理任务的复杂度和占用CPU资源，长时间占有CPU资源会降低系统的实时性及导致任务翻转（高优先级任务未能及时执行），或者中断响应的任务未能执行。

3.总结
1）“成对出现”，与malloc/free、new/delete内存分配类似，保证“成对出现”。调度锁上锁和解锁必须在同一线程内，理论上在线程内其他地方解锁都可以，但良好的习惯应该保证在同一函数内。
2）可以嵌套使用，但仍要遵守“成对出现”规则，每一次上锁，对应一次解锁，RTT的调度器锁最大嵌套深度是65535。
3）注意逻辑条件，考虑是否存在某种条件下直接执行函数返回，但并未解锁。
4）上锁任务占用的CPU资源应该尽可能小，并及时退出。
5）如出现前面提到类似的现象，可参考本文。