RAW OS 基于STM32F1/F4 学习笔记 资源共享与临界区问题
昨天用了很多时间实现QM应用于RAW OS 和出去放松。昨天刚实现QM移植到 RAW OS 上还是比较激动的，现在想想也就那么回事。
好，今天的任务是解决RAW OS 的资源共享的实现方法。
计划：
资源共享的具体实现方法：
1.开关中断：可以说是最直接的方法，中断一关，OS TICK就出不来了，就不存在任务抢占，同时，中断进不来，也就没有ISR和当前任务抢资源了。
实现方法RAW_CPU_DISABLE();
2.开关系统抢占。
实现方法实现方法 raw_disable_sche();
3.信号量
实现方法 函数位于raw_sem.c
4.互斥量
实现方法 函数位于 raw_mutex.c
4种方法在RAW OS中的具体应用：
1.开关中断：
基本内核中所有的临界区实现都是用的开关中断的方法，如消息队列，任务操作，内存分配，调度器。
2.开关系统抢占：
内核中软件定时器，消息队列mqueu是用开关系统抢占实现临界的。
3.信号量与互斥量
全局搜索raw_semaphore_create与raw_mutex_create是没有具体的应用的，可见，这两种资源共享实现方式是为用户提供的。
总结：
首先是，为什么存在临界区呢，jorya_txj的原文使我收获很大，因此贴上来
假设有以下代码:
int x;
void process_data()
{
x++;
}
假如在一个可以抢占的操作系统上有两个任务task1, task2, 全局变量x 的初始值为0, 现在两个任务task1, task2 同时去访问process_data 这个函数，两个任务各执行一次process_data 这个函数，等到两个人执行完毕后，试问x的值是多少？大部分人可能会回答为2。没有操作系统的时候，的却不错，调用函数2次，就是2.问题是有了操作系统就没这么简单了，一个任务执行期间，随时可能会被另外一个任务给打断，这样就会造成临界区的问题。
首先明确一个基本概念，在操作系统中每一个任务都有自己的一套寄存器，各个任务间的寄存器值很可能是不一样的。
下面来具体分析这个问题产生的根本原因：
x++不是一个原子型的操作，它的汇编函数有3句，分别是:
1 ldr r1,
2 add r1, r1, #1
3 strr1
如果有以下流程，参照下图：
http://cache.amobbs.com/new2012/forum/201311/03/20145711afm3maxfc2hjmm.png.thumb.jpg
假如任务task1 刚执行完(2)即 add r1, r1,#1, 因为是可以抢占的操作系统，所以被高优先级任务task 2 给抢占了，然后task 2 执行完(3) (4) (5)这三个步骤之后还给任务task 1, 最后task1 执行完(6)。
如前所述，图中的task1 和task2 的寄存器值是不同的，因为任务各自有自己的一套寄存器。读者可以推导一下，x 的最终值在内存中是1而不是2！
所以在多任务的情况下，共同去访问一个全局变量，会产生临界区的问题，如之前所述最终值可能是不确定的，可能是1也可能是2，所以需要采用操作系统的一定机制去保护它。
接下来谈谈怎么去解决这个问题。
解决方式一：
void process_data()
{
RAW_CPU_DISABLE();
x++;
RAW_CPU_ENABLE();
}
如上代码关了中断的话，任务也就不能被抢了，而且x++的速度很快，推荐使用这样的方式。
解决方式二：
void __process_data()
{
x++;
}
void process_data()
{
raw_disable_sche()；
__process_data();
raw_enable_sche()；
}
如上代码关了系统抢占后，任务之间的调度被禁止。
解决方式三：
void __process_data()
{
x++;
}
void process_data()
{
lock()；
__process_data();
unlock ()；
}
如上代码加软件锁之后，只能有一个任务处理此段临界区，lock可以是semaphore 或者mutex.
对于软件部分的临界区，往往要保护的是整个全局变量所引发的一系列逻辑。而不仅是保护那个全局变量，读者需要仔细体会。
因为临界问题项目中经常会遇到，所以，前几节都做的验证性试验,暂且不做啦.
楼主辛苦。
顶。。。 临界区的问题是至关重要的问题，也是菜鸟和老鸟的根本区别之一，对于临界区的全面理解往往可能需要几年的摸索过程，目前先记住有这样的问题，在实践中多摸索思考，用于实践解决问题。 mark
页:
[1]