1. 实验目的

编写内核代码或驱动代码时需要留意共享资源的保护，防止共享资源被并发访问。所谓并发访问，是指多个内核路径同时访问和操作数据，就有可能发生相互覆盖共享数据的情况，造成被访问数据的不一致。内核路径可以是一个内核执行路径、中断处理程序或者内核线程等。并发访问可能会造成系统不稳定或产生错误，且很难跟踪和调试。

在计算机术语中，临界区是指访问和操作共享数据的代码段，其中的资源无法同时被多个执行线程访问，访问临界区的执行线程或代码路径称为并发源。为了避免访问临界区，开发者必须保证访问临界区的原子性，即在临界区内不能有多个并发源同时执行，整个临界区就像一个不可分割的整体。

本章主要是学习和了解如何在Linux驱动中处理并发。

2. 常见的保护机制

Linux提供了多种并发访问的保护机制，如原子操作、自旋锁、信号量、互斥锁、读写锁、RCU等。

2.1 原子操作

原子操作是指保证指令以原子的方式执行，执行过程不会被打断。一般原子操作用于变量或者位操作。

2.1.1 原子整型操作API函数

Linux 内核定义了叫做 atomic_t 的结构体来完成整形数据的原子操作，在使用中用原子变量来代替整型变量，此结构体定义在 include/linux/types.h 文件中，定义如下：

typedef struct {
    int counter;
} atomic_t;

如果要使用原子操作 API 函数，首先要先定义一个atomic_t的变量，如下所示：

atomic_t a; //定义 a

也可以在定义原子变量的时候给原子变量赋初值，如下所示：

atomic_t b = ATOMIC_INIT(0); //定义原子变量 b 并赋初值为 0

可以通过宏 ATOMIC_INIT 向原子变量赋初值。
原子变量有了，接下来就是对原子变量进行操作，比如读、写、增加、减少等等， Linux 内核提供了大量的原子操作 API 函数，如表 47.2.2.1 所示：

如果使用 64 位的 SOC 的话，就要用到 64 位的原子变量， Linux 内核也定义了 64 位原子
结构体，如下所示：

typedef struct {
    long long counter;
} atomic64_t;

相应的也提供了 64 位原子变量的操作 API 函数，这里我们就不详细讲解了，和上表中的 API 函数有用法一样，只是将atomic_前缀换为atomic64_，将 int 换为 long long。如果使用的是 64 位的 SOC，那么就要使用 64 位的原子操作函数。 Cortex-A7 是 32 位的架构，所以本书中只使用表 中的 32 位原子操作函数。原子变量和相应的 API 函数使用起来很简单，参考如下示例：

atomic_t v = ATOMIC_INIT(0); /* 定义并初始化原子变零 v=0 */
atomic_set(&v, 10); /* 设置 v=10 */
atomic_read(&v); /* 读取 v 的值，肯定是 10 */
atomic_inc(&v); /* v 的值加 1， v=11 */

2.1.2 原子位操作API函数

位操作也是很常用的操作， Linux 内核也提供了一系列的原子位操作 API 函数，只不过原子位操作不像原子整形变量那样有个 atomic_t 的数据结构，原子位操作是直接对内存进行操作，

2.2 自旋锁

2.2.1 自旋锁简介

原子操作只能对整形变量或者位进行保护，但是，在实际的使用环境中怎么可能只有整形变量或位这么简单的临界区。举个最简单的例子，设备结构体变量就不是整型变量，我们对于结构体中成员变量的操作也要保证原子性，在线程 A 对结构体变量使用期间，应该禁止其他的线程来访问此结构体变量，这些工作原子操作都不能胜任，需要本节要讲的锁机制，在 Linux内核中就是自旋锁。

当一个线程要访问某个共享资源的时候首先要先获取相应的锁， 锁只能被一个线程持有，只要此线程不释放持有的锁，那么其他的线程就不能获取此锁。对于自旋锁而言，如果自旋锁正在被线程 A 持有，线程 B 想要获取自旋锁，那么线程 B 就会处于忙循环-旋转-等待状态，线程 B 不会进入休眠状态或者说去做其他的处理，而是会一直傻傻的在那里“转圈圈”的等待锁可用。

比如现在有个公用电话亭，一次肯定只能进去一个人打电话，现在电话亭里面有人正在打电话，相当于获得了自旋锁。此时你到了电话亭门口，因为里面有人，所以你不能进去打电话，相当于没有获取自旋锁，这个时候你肯定是站在原地等待，你可能因为无聊的等待而转圈圈消遣时光，反正就是哪里也不能去，要一直等到里面的人打完电话出来。终于，里面的人打完电话出来了，相当于释放了自旋锁，这个时候你就可以使用电话亭打电话了，相当于获取到了自旋锁。

自旋锁的“自旋”也就是“原地打转”的意思，“原地打转”的目的是为了等待自旋锁可以用，可以访问共享资源。把自旋锁比作一个变量 a，变量 a=1 的时候表示共享资源可用，当 a=0的时候表示共享资源不可用。现在线程 A 要访问共享资源，发现 a=0(自旋锁被其他线程持有)，那么线程 A 就会不断的查询 a 的值，直到 a=1。从这里我们可以看到自旋锁的一个缺点：那就等待自旋锁的线程会一直处于自旋状态，这样会浪费处理器时间，降低系统性能，所以自旋锁的持有时间不能太长。所以自旋锁适用于短时期的轻量级加锁，如果遇到需要长时间持有锁的场景那就需要换其他的方法了，这个我们后面会讲解。

Linux 内核使用结构体 spinlock_t 表示自旋锁，结构体定义如下所示：

64 typedef struct spinlock {
65         union {
66             struct raw_spinlock rlock;
67
68 #ifdef CONFIG_DEBUG_LOCK_ALLOC
69 # define LOCK_PADSIZE (offsetof(struct raw_spinlock, dep_map))
70             struct {
71                 u8 __padding[LOCK_PADSIZE];
72                 struct lockdep_map dep_map;
73             };
74 #endif
75         };
76 } spinlock_t;

在使用自旋锁之前，肯定要先定义一个自旋锁变量，定义方法如下所示：

spinlock_t lock; //定义自旋锁

定义好自旋锁变量以后就可以使用相应的 API 函数来操作自旋锁。

2.2.2 自旋锁API函数

最基本的自旋锁 API 函数如下表所示：

上表中的自旋锁API 函数适用于SMP或支持抢占的单CPU下线程之间的并发访问，也就是用于线程与线程之间，被自旋锁保护的临界区一定不能调用任何能够引起睡眠和阻塞的API 函数，否则的话会可能会导致死锁现象的发生。自旋锁会自动禁止抢占，也就说当线程 A得到锁以后会暂时禁止内核抢占。如果线程 A 在持有锁期间进入了休眠状态，那么线程 A 会自动放弃 CPU 使用权。线程 B 开始运行，线程 B 也想要获取锁，但是此时锁被 A 线程持有，而且内核抢占还被禁止了！线程 B 无法被调度出去，那么线程 A 就无法运行，锁也就无法释放，好了，死锁发生了！

上表中的 API 函数用于线程之间的并发访问，如果此时中断也要插一脚，中断也想访问共享资源，那该怎么办呢？首先可以肯定的是，中断里面可以使用自旋锁，但是在中断里面使用自旋锁的时候，在获取锁之前一定要先禁止本地中断(也就是本 CPU 中断，对于多核 SOC
来说会有多个 CPU 核)，否则可能导致锁死现象的发生，如图 47.3.2.1 所示：

在图 47.3.2.1 中，线程 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，因为这一组函数会保存中断状态，在释放锁的时候会恢复中断状态。一般在线程中使用 spin_lock_irqsave/spin_unlock_irqrestore，在中断中使用 spin_lock/spin_unlock，示例代码如下所示：

1 DEFINE_SPINLOCK(lock) /* 定义并初始化一个锁 */
2
3
/* 线程 A */
4 void functionA (){
5         unsigned long flags; /* 中断状态 */
6         spin_lock_irqsave(&lock, flags) /* 获取锁 */
7         /* 临界区 */
8         spin_unlock_irqrestore(&lock, flags) /* 释放锁 */
9 }
10
11 /* 中断服务函数 */
12 void irq() {
13         spin_lock(&lock) /* 获取锁 */
14         /* 临界区 */
15         spin_unlock(&lock) /* 释放锁 */
16 }

下半部(BH)也会竞争共享资源，有些资料也会将下半部叫做底半部。关于下半部后面的章节会讲解，如果要在下半部里面使用自旋锁，可以使用下表中的 API 函数：

2.2.3 其它类型的锁

在自旋锁的基础上还衍生出了其他特定场合使用的锁，这些锁在驱动中其实用的不多，更多的是在 Linux 内核中使用，本节我们简单来了解一下这些衍生出来的锁。

1、读写自旋锁

现在有个学生信息表，此表存放着学生的年龄、家庭住址、班级等信息，此表可以随时被修改和读取。此表肯定是数据，那么必须要对其进行保护，如果我们现在使用自旋锁对其进行保护。每次只能一个读操作或者写操作，但是，实际上此表是可以并发读取的。只需要保证在修改此表的时候没人读取，或者在其他人读取此表的时候没有人修改此表就行了。也就是此表的读和写不能同时进行，但是可以多人并发的读取此表。

像这样，当某个数据结构符合读/写或生产者/消费者模型的时候就可以使用读写自旋锁。

读写自旋锁为读和写操作提供了不同的锁，一次只能允许一个写操作，也就是只能一个线程持有写锁，而且不能进行读操作。但是当没有写操作的时候允许一个或多个线程持有读锁，可以进行并发的读操作。 Linux 内核使用 rwlock_t 结构体表示读写锁，结构体定义如下(删除了
条件编译)：

typedef struct {
    arch_rwlock_t raw_lock;
} rwlock_t;

读写锁操作 API 函数分为两部分，一个是给读使用的，一个是给写使用的，这些 API 函数如下表所示，

2、顺序锁

顺序锁在读写锁的基础上衍生而来的，使用读写锁的时候读操作和写操作不能同时进行。使用顺序锁的话可以允许在写的时候进行读操作，也就是实现同时读写，但是不允许同时进行并发的写操作。虽然顺序锁的读和写操作可以同时进行，但是如果在读的过程中发生了写操作，最好重新进行读取，保证数据完整性。顺序锁保护的资源不能是指针，因为如果在写操作的时候可能会导致指针无效，而这个时候恰巧有读操作访问指针的话就可能导致意外发生，比如读取野指针导致系统崩溃。 Linux 内核使用 seqlock_t 结构体表示顺序锁，结构体定义如下：

typedef struct {
    struct seqcount seqcount;
    spinlock_t lock;
} seqlock_t;

关于顺序锁的 API 函数如下表所示：

2.2.4 自旋锁使用注意事项

综合前面关于自旋锁的信息，我们需要在使用自旋锁的时候要注意一下几点：

1、因为在等待自旋锁的时候处于“自旋”状态，因此锁的持有时间不能太长，一定要短，否则的话会降低系统性能。如果临界区比较大，运行时间比较长的话要选择其他的并发处理方式，比如稍后要讲的信号量和互斥体。
2、自旋锁保护的临界区内不能调用任何可能导致线程休眠的 API 函数，否则的话可能导致死锁。
3、不能递归申请自旋锁，因为一旦通过递归的方式申请一个你正在持有的锁，那么你就必须“自旋”，等待锁被释放，然而你正处于“自旋”状态，根本没法释放锁。结果就是自己把自己锁死了！
4、在编写驱动程序的时候我们必须考虑到驱动的可移植性，因此不管你用的是单核的还是多核的 SOC，都将其当做多核 SOC 来编写驱动程序。

2.3 信号量

2.3.1 信号量简介

大家如果有学习过 FreeRTOS 或者 UCOS 的话就应该对信号量很熟悉，因为信号量是同步的一种方式。 Linux 内核也提供了信号量机制，信号量常常用于控制对共享资源的访问。

举一个很常见的例子，某个停车场有 100 个停车位，这 100 个停车位大家都可以用，对于大家来说这100 个停车位就是共享资源。假设现在这个停车场正常运行，你要把车停到这个这个停车场肯定要先看一下现在停了多少车了？还有没有停车位？当前停车数量就是一个信号量，具体的停车数量就是这个信号量值，当这个值到 100 的时候说明停车场满了。停车场满的时你可以等一会看看有没有其他的车开出停车场，当有车开出停车场的时候停车数量就会减一，也就是说信号量减一，此时你就可以把车停进去了，你把车停进去以后停车数量就会加一，也就是信号量加一。这就是一个典型的使用信号量进行共享资源管理的案例，在这个案例中使用的就是计数型信号量。

相比于自旋锁，信号量可以使线程进入休眠状态，比如 A 与 B、 C 合租了一套房子，这个房子只有一个厕所，一次只能一个人使用。某一天早上 A 去上厕所了，过了一会 B 也想用厕所，因为 A 在厕所里面，所以 B 只能等到 A 用来了才能进去。 B 要么就一直在厕所门口等着，等 A 出来，这个时候就相当于自旋锁。 B 也可以告诉 A，让 A 出来以后通知他一下，然后 B 继续回房间睡觉，这个时候相当于信号量。

可以看出，使用信号量会提高处理器的使用效率，毕竟不用一直傻乎乎的在那里“自旋”等待。但是，信号量的开销要比自旋锁大，因为信号量使线程进入休眠状态以后会切换线程，切换线程就会有开销。总结一下信号量的特点：

1、因为信号量可以使等待资源线程进入休眠状态，因此适用于那些占用资源比较久的场合。
2、因此信号量不能用于中断中，因为信号量会引起休眠，中断不能休眠。
3、如果共享资源的持有时间比较短，那就不适合使用信号量了，因为频繁的休眠、切换线程引起的开销要远大于信号量带来的那点优势。

信号量有一个信号量值，相当于一个房子有 10 把钥匙，这 10 把钥匙就相当于信号量值为10。因此，可以通过信号量来控制访问共享资源的访问数量，如果要想进房间，那就要先获取一把钥匙，信号量值减 1，直到 10 把钥匙都被拿走，信号量值为 0，这个时候就不允许任何人进入房间了，因为没钥匙了。如果有人从房间出来，那他要归还他所持有的那把钥匙，信号量值加 1，此时有 1 把钥匙了，那么可以允许进去一个人。相当于通过信号量控制访问资源的线程数，在初始化的时候将信号量值设置的大于 1，那么这个信号量就是计数型信号量，计数型
信号量不能用于互斥访问，因为它允许多个线程同时访问共享资源。如果要互斥的访问共享资源那么信号量的值就不能大于 1，此时的信号量就是一个二值信号量。

2.3.2 信号量API函数

Linux 内核使用 semaphore 结构体表示信号量，结构体内容如下所示：

struct semaphore {
    raw_spinlock_t lock;
    unsigned int count;
    struct list_head wait_list;
};

要想使用信号量就得先定义，然后初始化信号量。有关信号量的 API 函数如下表所示：

信号量的使用如下所示：

struct semaphore sem; /* 定义信号量 */
sema_init(&sem, 1); /* 初始化信号量 */
down(&sem); /* 申请信号量 */
/* 临界区 */
up(&sem); /* 释放信号量 */

2.4 互斥体

2.4.1 互斥体简介

在 FreeRTOS 和 UCOS 中也有互斥体，将信号量的值设置为 1 就可以使用信号量进行互斥访问了，虽然可以通过信号量实现互斥，但是 Linux 提供了一个比信号量更专业的机制来进行互斥，它就是互斥体—mutex。互斥访问表示一次只有一个线程可以访问共享资源，不能递归申请互斥体。在我们编写 Linux 驱动的时候遇到需要互斥访问的地方建议使用 mutex。

使用 mutex 结构体表示互斥体，定义如下(省略条件编译部分)：

struct mutex {
    /* 1: unlocked, 0: locked, negative: locked, possible waiters */
    atomic_t count;
    spinlock_t wait_lock;
};

在使用 mutex 之前要先定义一个 mutex 变量。在使用 mutex 的时候要注意如下几点：
1、 mutex 可以导致休眠，因此不能在中断中使用 mutex，中断中只能使用自旋锁。
2、和信号量一样， mutex 保护的临界区可以调用引起阻塞的 API 函数。
3、因为一次只有一个线程可以持有 mutex，因此，必须由 mutex 的持有者释放 mutex。并
且 mutex 不能递归上锁和解锁。

2.4.2 互斥体API函数

有关互斥体的 API 函数如下表所示：

互斥体的使用如下所示：

1 struct mutex lock; /* 定义一个互斥体 */
2 mutex_init(&lock); /* 初始化互斥体 */
3
4 mutex_lock(&lock); /* 上锁 */
5 /* 临界区 */
6 mutex_unlock(&lock); /* 解锁 */

关于 Linux 中的并发和竞争就讲解到这里， Linux 内核还有很多其他的处理并发和竞争的机制，本章我们主要讲解了常用的原子操作、自旋锁、信号量和互斥体。以后我们在编写 Linux驱动的时候就会频繁的使用到这几种机制，希望大家能够深入理解这几个常用的机制。

3. Linux并发与竞争实验

1. 并发与竞争--原子变量
2. 并发与竞争--spinlock
3. 并发与竞争--信号量
4. 并发与竞争--mutex