临界区问题以和解决方法.docVIP

临界区问题的产生，以及解决方法。 临界区问题是嵌入式软件编程一个不得不面对的关键性问题。特别对于底层驱动，代码在内存中只有一份，上层的多任务或者多进程，都会对同一个驱动去访问，这样不可避免的遇到了任务之间打架的问题，处理好这个问题是区分一个菜鸟和老鸟的根本性关键之一。 接下来谈谈临界区产生的原因： 假设有以下代码: 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, [mem] 2 add r1, r1, #1 3 strr1 [mem] 如果有以下流程，参照下图： 假如任务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. 之前的例子演示的是任务和任务之间的打架冲突，会造成临界区问题，那如果是中断和任务之间的打架冲突呢？答案是一致的，唯一不同点是任务和任务之间的冲突可以有多种保护方式，但是任务和中断之间的冲突只能用关中断去保护，即采用之前的解决方式一来解决冲突。 临界区的产生原因有很多，往往是复杂的，考虑如下的fifo循环缓冲区: struct raw_fifo { RAW_U32 in; (1) RAW_U32 out; (2) RAW_U32 mask; void *data; RAW_U32 free_bytes; RAW_U32 size; }; 处是fifo的的写指针，（2）处是fifo读指针 下面的代码是往fifo 里面写数据。 RAW_U32 fifo_in(struct raw_fifo *fifo, const void *buf, RAW_U32 len) { RAW_U32 l; RAW_SR_ALLOC(); RAW_CPU_DISABLE(); (1) l = fifo_unused(fifo); if (len l) len = l; fifo_copy_in(fifo, buf, len, fifo-in); (2) fifo-in += len;