进程上下文执行环境还有中断上下文执行环境，并且中断上下文优先级比较高，可以随时打断进程的执行，因此情况更加复杂。内核当中提供了不同的同步机制。比如说信号量，自旋锁，rcu，原子变量等等。他们各自都有自己适用的场景。

首先我们开始我们进程与进程的同步机制。

在驱动中，有些进程只允许打开一次。

我们用xxx_count来表示打开标志位。

int xxx_count =1 //驱动中的全局变量

...

int hello_open(struct *p,struct file *f){

if(xxx_count){

return -EBUSY; //打开失败

}

++xxx_count；

return 0； //打开成功

}jin

这个伪代码的意思是，当第一个进程执行open时，因为初始化xxx_count = 0；则不会进入if语句里面。xxx_count加1；

当第二个进入的时候，因为xxx_count是为1的状态，所以进去if语句里面了。返回错误

同样第三个或者第四个都会报错。

逻辑上是正常的。但是系统的执行流程并非如此的情况。而是如下图：

t2时刻：进程A对xxx_count加1

t3时刻：进程B也对xxx_count加1

此后，进程A和进程B的结果都是可以打开设备的。这样就不符合我们的初衷了。

那么该怎么解决这个问题呢？

术语：

共享资源：xxx_count就是一个共享资源

竞态问题：并发执行单元对共享资源的同时访问就会引发竞态问题

临界区：访问共享资源的代码块叫做临界区