高效实时操作系统原理以及实践-临界区问题的产生，以及...

lulu爱

临界区问题是嵌入式软件编程一个不得不面对的关键性问题。特别对于底层驱动，代码在内存中只有一份，上层的多任务或者多进程，都会对同一个驱动去访问，这样不可避免的遇到了任务之间打架的问题，处理好这个问题是区分一个菜鸟和老鸟的根本性关键之一。

接下来谈谈临界区产生的原因：

假设有以下代码:

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;
       
};

(1)        处是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;                                                                                          (3)

        fifo->free_bytes -= len;

        RAW_CPU_ENABLE();                                                                                (4)
        return len;
}

(2)处代码为写入数据到fifo 中。
(3)处代码为更新fifo 写指针。

可以看到(1) 处为关cpu 中断，(4) 处为开cpu 中断。这样做的目的是保护临界区(2)和(3)处，(2) 和(3) 处是一个连贯的逻辑，这块逻辑是不能被打断的。
假设有两个任务task1, task2 同时执行fifo_in，当task1 执行完(2)之后，被高优先级任务task2抢占，当task2 执行(2)处代码时会覆盖task1之前写到fifo里面的数据，因为task1还未更新(3)处的写指针。 这个例子里用到了开关中断来保护临界区，因为中断里也会用到fifo 的api.

所以对于软件部分的临界区，往往要保护的是整个全局变量所引发的一系列逻辑。而不仅是保护那个全局变量，读者需要仔细体会。


接下来谈谈硬件临界区。所谓的硬件临界区是指一个任务在访问硬件设备的时候，比如写操作，这个时候不允许有其它任务，或者中断去访问这个操作，不然整个写的时序就被破坏了，很可能结果不可预料，往往会挂机。举例如下：

__nand_write()
{
…………………………..
……………………………
…………………………….

}


nand_write()
{
        lock()                                                                                                (1)
        __nand_write();
        unlock();                                                                                        (2)

}


(1)处和(2)处的锁往往是semphore 或者mutex, 推荐使用mutex, 因为可以更好地解决优先级反转的问题。

wye11083

其实，对于MCU，Lock一次的成本太高。最好的办法是利用CPU实现2^N个固定锁，这样CPU可以在5~10个周期内锁住，完全由硬件控制，OS负责为程序请求锁提供偏移量。这样，在基于多CPU系统内，每个CPU共享这2^N个锁，同步时间可以控制在20个周期内，远远快于内存锁，除了锁数量较少。但是哪个程序会用到那么多锁呢？

lulu爱

利用CPU实现2^N个固定锁?请教如何实现？你是指的软件锁还是什么？我的前提是单个cpu, raw os 未来不会走smp架构只会走amp架构。