临界区保护

只看该作者 · 2019-6-22 14:48

跨度稍微大一点，现在我们来讨论一个关于共享资源的问题。例如在程序中定义了一个全局数组变量delaytimes[] 这个全局变量除了运行的任务可以访问，中断异常处理也可以访问，那么问题来了，任务1先对delaytimes[] 进行读操作，在任务1读的过程中Systick触发了任务切换，这个时候切换到了任务2，恰巧任务2对delaytimes[] 写操作，改变了delaytimes[]的一部分内容，当任务再切换回任务1的时候，接着读取delaytimes[] 中的内容，这样后面再读取的数据就不确定是否正确了。

只看该作者 · 2019-6-22 14:48

具体见下图

只看该作者 · 2019-6-22 14:49

为了解决任务和任务，任务和中断之间共享资源的问题，我们引入了临界区保护，当要访问共享资源时，该代码段先进入临界区保护，操作完后退出临界区保护。其目的是在临界区保护段不会受到任何打扰，任务不会被切换。那么临界区保护是如何做到的呢？简单的说就是关中断，开中断的操作，进入临界区时关中断不再进行任务切换，退出临界区保护时恢复中断。遇到一个很聪明的学生，他提出了一个关于中断嵌套的问题：如果任务1里面某一段区域先对共享资源1访问，然后再访问资源1操作里又对资源2访问，那简单的关中断，开中断就不再奏效了。

只看该作者 · 2019-6-22 14:50

共享资源访问嵌套具体模型如下：

只看该作者 · 2019-6-22 14:50

特提出了一种解决方式，即是在关中断的时候，保存相关参数，在退出临界保护时用此参数来恢复中断。

只看该作者 · 2019-6-22 14:51

编写进入临界区和退出临界区函数，具体代码如下，后续在需要的地方添加临界区保护代码来确保整个共享资源被正确的读取和写入。
//进入临界保护区
uint32_t TaskEnterCritical()
{
uint32_t primask;
   primask = __get_PRIMASK();
   __disable_irq();  //关中断
return primask;
}
//退出临界保护区
void TaskExitCritical(uint32_t status)
{
  __set_PRIMASK(status);
}

只看该作者 · 2019-6-22 14:51

本次临界区保护比较简单，大家明白原理即可。

只看该作者 · 2019-6-22 21:40

跑系统的？

只看该作者 · 2019-6-24 16:41

解决共享资源问题，往往不推荐使用进入临界区的方式，优先使用资源的守护任务方式，或者挂起调度器的方式。

只看该作者 · 2019-6-29 18:44

caoenq 发表于 2019-6-24 16:41
解决共享资源问题，往往不推荐使用进入临界区的方式，优先使用资源的守护任务方式，或者挂起调度器的方式。 ...

是的，不着急后面一步一步来

只看该作者 · 2019-6-29 18:45

玛尼玛尼哄发表于 2019-6-22 21:40
跑系统的？

是啊，rtos

只看该作者 · 2020-2-24 08:37

方案一、既然共享资源作成数组了，可以用改用队列吗？
好处：其他写共享资源的任务的操作不会影响到读任务读的数据吧,而且有情况能马上记录不会丢失。也不用当心临界保护嵌套使用。
缺点：资源需要较多，而且也怕切换时其他任务出现读处理资源任务（设计时需要注意，只有一处调用读处理函数的任务）。
方案二、可以把读处理共享资源的任务优先级设置成比写处理共享资源的任务的优先级高，这样只要读任务没有使用阻塞函数前，就不会先执行写共享资源，
优点:不用当心写共享资源的任务会抢占读共享资源的任务，能比较快的读取数据，资源占用较小，也不用当心临界保护嵌套使用。
缺点：写的共享资源可能会覆盖丢失，而且设计时需要注意优先级和阻塞，不能出现写任务比读任务优先级高，不能再读处理过程中出现阻塞(包括嵌套里)。
方案三、使用能在中断临界保护的函数（即能嵌套的临界保护函数，freertos有现成）
优点:设计简单不容易出现设计上的问题。
缺点:写的共享资源可能会覆盖丢失，频繁调用开关中断会影响RTOS中断的实时性（不知道会不会影响时序？）
最近刚刚学RTOS，上面有错的地方希望指出。

临界区保护

技术高手奖章

以坛为家

涓涓之细流