一、并发与竞争
- 并发与竞争简介
Linux 系统是个多任务操作系统，会存在多个任务同时访问同一片内存区域，这些任务可能会相互覆盖这段内存中的数据，造成内存数据混乱。针对这个问题必须要做处理，严重的话可能会导致系统崩溃。现在的 Linux 系统并发产生的原因很复杂，总结一下有下面几个主要原因：
①、多线程并发访问，Linux 是多任务(线程)的系统，所以多线程访问是最基本的原因。
②、抢占式并发访问，从 2.6 版本内核开始，Linux 内核支持抢占，也就是说调度程序可以在任意时刻抢占正在运行的线程，从而运行其他的线程。
③、中断程序并发访问，这个无需多说，学过 STM32 的同学应该知道，硬件中断的权利可是很大的。
④、SMP(多核)核间并发访问，现在 ARM 架构的多核 SOC 很常见，多核 CPU 存在核间并发访问。
并发访问带来的问题就是竞争，学过FreeRTOS和UCOS的同学应该知道临界区这个概念，所谓的临界区就是共享数据段，对于临界区必须保证一次只有一个线程访问，也就是要保证临界区是原子访问的。我们都知道，原子化学反应不可再分的基本微粒，这里的原子访问就表示这一个访问是一个步骤，不能再进行拆分。如果多个线程同时操作临界区就表示存在竞争，我们在编写驱动的时候一定要注意避免并发和防止竞争访问。很多 Linux 驱动初学者往往不注意这一点，在驱动程序中埋下了隐患，这类问题往往又很不容易查找，导致驱动调试难度加大、费时费力。所以我们一般在编写驱动的时候就要
考虑到并发与竞争，而不是驱动都编写完了然后再处理并发与竞争。
- 保护内容是什么
前面一直说要防止并发访问共享资源，换句话说就是要保护共享资源，防止进行并发访问。那么问题来了，什么是共享资源？现实生活中的公共电话、共享单车这些是共享资源，我们都很容易理解，那么在程序中什么是共享资源？也就是保护的内容是什么？我们保护的不是代码，而是数据！某个线程的局部变量不需要保护，我们要保护的是多个线程都会访问的共享数据。一个整形的全局变量 a 是数据，一份要打印的文档也是数据，虽然我们知道了要对共享数据进行保护，那么怎么判断哪些共享数据要保护呢？找到要保护的数据才是重点，而这个也是难点，因为驱动程序各不相同，那么数据也千变万化，一般像全局变量，设备结构体这些肯定是要保护的，至于其他的数据就要根据实际的驱动程序而定了。
接下来就介绍几种解决并发与竞争的方法：原子操作，自旋锁，信号量以及互斥体。
二、原子操作
- 原子操作简介
首先看一下原子操作，原子操作就是指不能在进一步分割的操作，一般原子操作用于变量或者位操作。假如现在要对无符号整形变量 a 赋值，值为 3，对于 C 语言来讲很简单，直接就是：
a = 3
但是 C 语言要先编译为成汇编指令，ARM 架构不支持直接对寄存器进行读写操作，比如要借助寄存器 R0、R1 等来完成赋值操作。假设变量 a 的地址为0X3000000，“a=3”这一行 C语言可能会被编译为如下所示的汇编代码：
1 ldr r0, =0X30000000 /* 变量 a 地址 */
2 ldr r1, = 3 /* 要写入的值 */
3 str r1, [r0] /* 将 3 写入到 a 变量中 */
示例代码只是一个简单的举例说明，实际的结果要比示例代码复杂的多。从上述代码可以看出，C 语言里面简简单单的一句“a=3”，编译成汇编文件以后变成了 3 句，那么程序在执行的时候肯定是按照示例代码中的汇编语句一条一条的执行。假设现在线程 A要向 a 变量写入 10 这个值，而线程 B 也要向 a 变量写入 20 这个值，我们理想中的执行顺序如下图所示：
按照上图所示的流程，确实可以实现线程 A 将 a 变量设置为 10，线程 B 将 a 变量设置为 20。但是实际上的执行流程可能如下图所示：
按照上图 所示的流程，线程 A 最终将变量 a 设置为了 20，而并不是要求的 10！线程B 没有问题。这就是一个最简单的设置变量值的并发与竞争的例子，要解决这个问题就要保证示例代码中的三行汇编指令作为一个整体运行，也就是作为一个原子存在。Linux 内核提供了一组原子操作 API 函数来完成此功能，Linux 内核提供了两组原子操作 API 函数，一组是对整形变量进行操作的，一组是对位进行操作的，我们接下来看一下这些 API 函数。
- 原子整形数据操作 API 函数
Linux 内核定义了叫做 atomic_t 的结构体来完成整形数据的原子操作，在使用中用原子变量来代替整形变量，此结构体定义在 include/linux/types.h 文件中，定义如下：
可以通过宏 ATOMIC_INIT 向原子变量赋初值。原子变量有了，接下来就是对原子变量进行操作，比如读、写、增加、减少等等，Linux 内核提供了大量的原子操作 API 函数，如下表所示：
举个简单的例子：
atomic_t v = ATOMIC_INIT(0); /* 定义并初始化原子变零 v=0 */
atomic_set(10); /* 设置 v=10 */
atomic_read(&v); /* 读取 v 的值，肯定是 10 */
atomic_inc(&v); /* v 的值加 1，v=11 */
- 原子位操作 API 函数
位操作也是很常用的操作，Linux 内核也提供了一系列的原子位操作 API 函数，只不过原子位操作不像原子整形变量那样有个 atomic_t 的数据结构，原子位操作是直接对内存进行操作，从函数形参就可以看出我们提供的是变量的地址，API 函数如下表所示：
| 函数 | 描述 |
|---|---|
| void set_bit(int nr, void *p) | 将 p 地址的第 nr 位置 1 |
| void clear_bit(int nr,void *p) | 将 p 地址的第 nr 位清零 |
| void change_bit(int nr, void *p) | 将 p 地址的第 nr 位进行翻转 |
| int test_bit(int nr, void *p) | 获取 p 地址的第 nr 位的值 |
| int test_and_set_bit(int nr, void *p) | 将 p 地址的第 nr 位置 1，并且返回 nr 位原来的值 |
| int test_and_clear_bit(int nr, void *p) | 将 p 地址的第 nr 位清零，并且返回 nr 位原来的值 |
| int test_and_change_bit(int nr, void *p) | 将 p 地址的第 nr 位翻转，并且返回 nr 位原来的值 |
三、自旋锁
- 自旋锁简介
原子操作只能对整形变量或者位进行保护，但是，在实际的使用环境中怎么可能只有整形变量或位这么简单的临界区。举个最简单的例子，设备结构体变量就不是整型变量，我们对于结构体中成员变量的操作也要保证原子性，在线程 A 对结构体变量使用期间，应该禁止其他的线程来访问此结构体变量，这些工作原子操作都不能胜任，需要本节要讲的锁机制，在 Linux内核中就是自旋锁。
当一个线程要访问某个共享资源的时候首先要先获取相应的锁，锁只能被一个线程持有，只要此线程不释放持有的锁，那么其他的线程就不能获取此锁。对于自旋锁而言，如果自旋锁正在被线程 A 持有，线程 B 想要获取自旋锁，那么线程 B 就会处于忙循环-旋转-等待状态，线程 B 不会进入休眠状态或者说去做其他的处理，而是会一直傻傻的在那里“转圈圈”的等待锁可用。比如现在有个公用电话亭，一次肯定只能进去一个人打电话，现在电话亭里面有人正在打电话，相当于获得了自旋锁。此时你到了电话亭门口，因为里面有人，所以你不能进去打电话，相当于没有获取自旋锁，这个时候你肯定是站在原地等待，你可能因为无聊的等待而转圈圈消遣时光，反正就是哪里也不能去，要一直等到里面的人打完电话出来。终于，里面的人打完电话出来了，相当于释放了自旋锁，这个时候你就可以使用电话亭打电话了，相当于获取到了自旋锁。
自旋锁的“自旋”也就是“原地打转”的意思，“原地打转”的目的是为了等待自旋锁可以用，可以访问共享资源。把自旋锁比作一个变量 a，变量 a=1 的时候表示共享资源可用，当 a=0的时候表示共享资源不可用。现在线程 A 要访问共享资源，发现 a=0(自旋锁被其他线程持有)，那么线程 A 就会不断的查询 a 的值，直到 a=1。从这里我们可以看到自旋锁的一个缺点：那就等待自旋锁的线程会一直处于自旋状态，这样会浪费处理器时间，降低系统性能，所以自旋锁的持有时间不能太长。所以自旋锁适用于短时期的轻量级加锁，如果遇到需要长时间持有锁的场景那就需要换其他的方法了。
在使用自旋锁之前，肯定要先定义一个自旋锁变量，定义方法如下所示：
spinlock_t lock; //定义自旋锁
定义好自旋锁变量以后就可以使用相应的 API 函数来操作自旋锁。
自旋锁API函数适用于SMP或支持抢占的单CPU下线程之间的并发访问，也就是用于线程与线程之间，被自旋锁保护的临界区一定不能调用任何能够引起睡眠和阻塞的API 函数，否则的话会可能会导致死锁现象的发生。自旋锁会自动禁止抢占，也就说当线程 A得到锁以后会暂时禁止内核抢占。如果线程 A 在持有锁期间进入了休眠状态，那么线程 A 会自动放弃 CPU 使用权。线程 B 开始运行，线程 B 也想要获取锁，但是此时锁被 A 线程持有，而且内核抢占还被禁止了！线程 B 无法被调度出去，那么线程 A 就无法运行，锁也就无法释放，好了，死锁发生了！
API 函数用于线程之间的并发访问，如果此时中断也要插一脚，中断也想访问共享资源，那该怎么办呢？首先可以肯定的是，中断里面可以使用自旋锁，但是在中断里面使用自旋锁的时候，在获取锁之前一定要先禁止本地中断(也就是本 CPU 中断，对于多核 SOC来说会有多个 CPU 核)，否则可能导致锁死现象的发生，如下图所示：
在上图中，线程 A 先运行，并且获取到了 lock 这个锁，当线程 A 运行 functionA 函数的时候中断发生了，中断抢走了 CPU 使用权。右边的中断服务函数也要获取 lock 这个锁，但是这个锁被线程 A 占有着，中断就会一直自旋，等待锁有效。但是在中断服务函数执行完之前，线程 A 是不可能执行的，线程 A 说“你先放手”，中断说“你先放手”，场面就这么僵持着，死锁发生！
最好的解决方法就是获取锁之前关闭本地中断，Linux 内核提供了相应的 API 函数，如下表所示：
使用 spin_lock_irq/spin_unlock_irq 的时候需要用户能够确定加锁之前的中断状态，但实际上内核很庞大，运行也是“千变万化”，我们是很难确定某个时刻的中断状态，因此不推荐使用spin_lock_irq/spin_unlock_irq。建议使用spin_lock_irqsave/spin_unlock_irqrestore，因为这一组函数会保存中断状态，在释放锁的时候会恢复中断状态。示例代码如下所示：
四、信号量
- 信号量简介
大家如果有学习过 FreeRTOS 或者 UCOS 的话就应该对信号量很熟悉，因为信号量是同步的一种方式。Linux 内核也提供了信号量机制，信号量常常用于控制对共享资源的访问。举一个很常见的例子，某个停车场有 100 个停车位，这 100 个停车位大家都可以用，对于大家来说这100 个停车位就是共享资源。假设现在这个停车场正常运行，你要把车停到这个这个停车场肯定要先看一下现在停了多少车了？还有没有停车位？当前停车数量就是一个信号量，具体的停车数量就是这个信号量值，当这个值到 100 的时候说明停车场满了。停车场满的时你可以等一会看看有没有其他的车开出停车场，当有车开出停车场的时候停车数量就会减一，也就是说信号量减一，此时你就可以把车停进去了，你把车停进去以后停车数量就会加一，也就是信号量加一。这就是一个典型的使用信号量进行共享资源管理的案例，在这个案例中使用的就是计数型信号量。
相比于自旋锁，信号量可以使线程进入休眠状态，比如 A 与 B、C 合租了一套房子，这个房子只有一个厕所，一次只能一个人使用。某一天早上 A 去上厕所了，过了一会 B 也想用厕所，因为 A 在厕所里面，所以 B 只能等到 A 用来了才能进去。B 要么就一直在厕所门口等着，等 A 出来，这个时候就相当于自旋锁。B 也可以告诉 A，让 A 出来以后通知他一下，然后 B 继续回房间睡觉，这个时候相当于信号量。可以看出，使用信号量会提高处理器的使用效率，毕竟不用一直傻乎乎的在那里“自旋”等待。但是，信号量的开销要比自旋锁大，因为信号量使线程进入休眠状态以后会切换线程，切换线程就会有开销。总结一下信号量的特点：
①、因为信号量可以使等待资源线程进入休眠状态，因此适用于那些占用资源比较久的场合。
②、因此信号量不能用于中断中，因为信号量会引起休眠，中断不能休眠。
③、如果共享资源的持有时间比较短，那就不适合使用信号量了，因为频繁的休眠、切换线程引起的开销要远大于信号量带来的那点优势。
信号量有一个信号量值，相当于一个房子有 10 把钥匙，这 10 把钥匙就相当于信号量值为10。因此，可以通过信号量来控制访问共享资源的访问数量，如果要想进房间，那就要先获取一把钥匙，信号量值减 1，直到 10 把钥匙都被拿走，信号量值为 0，这个时候就不允许任何人进入房间了，因为没钥匙了。如果有人从房间出来，那他要归还他所持有的那把钥匙，信号量值加 1，此时有 1 把钥匙了，那么可以允许进去一个人。相当于通过信号量控制访问资源的线程数，在初始化的时候将信号量值设置的大于 1，那么这个信号量就是计数型信号量，计数型信号量不能用于互斥访问，因为它允许多个线程同时访问共享资源。如果要互斥的访问共享资源那么信号量的值就不能大于 1，此时的信号量就是一个二值信号量。
- 信号量 API 函数
Linux 内核使用 semaphore 结构体表示信号量，结构体内容如下所示：
要想使用信号量就得先定义，然后初始化信号量。有关信号量的 API 函数如下表所示：
信号量的使用如下所示：
五、互斥体
- 互斥体简介
在 FreeRTOS 和 UCOS 中也有互斥体，将信号量的值设置为 1 就可以使用信号量进行互斥访问了，虽然可以通过信号量实现互斥，但是 Linux 提供了一个比信号量更专业的机制来进行互斥，它就是互斥体—mutex。互斥访问表示一次只有一个线程可以访问共享资源，不能递归申请互斥体。在我们编写 Linux 驱动的时候遇到需要互斥访问的地方建议使用 mutex。Linux 内核使用 mutex 结构体表示互斥体，定义如下(省略条件编译部分)：
在使用 mutex 之前要先定义一个 mutex 变量。在使用 mutex 的时候要注意如下几点：
①、mutex 可以导致休眠，因此不能在中断中使用 mutex，中断中只能使用自旋锁。
②、和信号量一样，mutex 保护的临界区可以调用引起阻塞的 API 函数。
③、因为一次只有一个线程可以持有 mutex，因此，必须由 mutex 的持有者释放 mutex。并且 mutex 不能递归上锁和解锁。
- 有关互斥体的 API 函数如下表所示：
互斥体的使用如下所示：
六、四种方法的使用方式举例(伪代码)
这四种常见的避免并发与竞争的方法，在平时使用的时候可以采取以下形式：
- 原子操作：重点是观察和原子相关的操作所处在哪一个函数中；主要是通过
lock变量的值来判断此时可以不可以操作（这里是初始值为1,1的时候可以执行，0的时候不可以），从而避免多个线程同时操作驱动或者是驱动中的共享数据。
atomic_t lock; /* 原子操作， */
/* 驱动入口函数 */
static int __init led_init(void)
{
/* 初始化原子变量 */
atomic_set(&lock, 1);
}
static int led_open(struct inode *inode, struct file *filp)
{
/* 判断lock */
if(!atomic_dec_and_test(&lock)) { /* 不能使用驱动 */
atomic_inc(&lock);
return -1;
}
return 0;
}
static int led_release(struct inode *inode, struct file *filp)
{
atomic_inc(&lock); /* 加一，释放驱动 */
return 0;
}
- 自旋锁：申请自旋锁之后，在释放自旋锁之前的安全区内对状态变量进行操作，通过该变量的值来判断能否执行。之所以这样，而不是直接不释放自旋锁直接到驱动程序结束正是因为前面说过的自旋锁的持有时间不能太长。所以我们使用一个状态变量来标志此时驱动程序能否被其他线程调用，这样只需要在设置状态变量的值的时候用自旋锁保护一下即可，以防止该全局变量被其他线程也操作。
int dev_status; /* 0表示设备可以使用，1表示不可使用 */
spinlock_t lock;
static int __init led_init(void)
{
/* 初始化自选锁 */
spin_lock_init(&lock);
dev_status = 0;
}
static int led_open(struct inode *inode, struct file *filp)
{
spin_lock(&lock);
if(dev_status) { /* 驱动不能使用 */
spin_unlock(&lock);
return -EBUSY;
}
dev_status++; /* 标记被使用 */
spin_unlock(&lock);
return 0;
}
static int led_release(struct inode *inode, struct file *filp)
{
spin_lock(&lock);
if(dev_status) {
dev_status--; /* 标记驱动可是使用 */
}
spin_unlock(&lock);
return 0;
}
- 信号量：我们只需要简单的调用两个API就可以，这种是我们设置只能同时有一个线程可以调用该驱动程序，当然你也可以设置成可以有多个。
down(&sem)会使sem的值减1，减1之前只要大于或等于1就可以执行驱动程序，否则就不行，因此当有一个线程将驱动程序中的sem的值减1变成0后，另外一个线程就不能调用该驱动程序了，只有当第一个线程执行完到最后执行up(&sem)将sem的值加1，此时其他的线程才可以调用该驱动程序。
struct semaphore sem;
/* 驱动入口函数 */
static int __init led_init(void)
{
/* 初始化信号量 */
sema_init(&sem, 1);
}
static int led_open(struct inode *inode, struct file *filp)
{
down(&sem);
return 0;
}
static int led_release(struct inode *inode, struct file *filp)
{
up(&sem);
return 0;
}
- 互斥体：和信号量同理，因为本身互斥体就可以用sem值为1的信号量来实现。
struct mutex lock
static int __init led_init(void)
{
/* 初始化互斥体 */
mutex_init(&lock);
}
static int led_open(struct inode *inode, struct file *filp)
{
mutex_lock(&lock);
return 0;
}
static int led_release(struct inode *inode, struct file *filp)
{
mutex_unlock(&lock);
return 0;
}