Linux 并发与竞争

一、前言

Linux是一个多任务操作系统，肯定会存在多个任务共同操作同一段内存或者设备的情况，
多个任务甚至中断都能访问的资源叫做共享资源。

二、并发与竞争

并发与竞争：
并发就是多个"用户"同时访问同一个共享资源，竞争就是多个线程争取同一个资源。
现在的 Linux 系统并发产生的原因很复杂，总结一下有下面几个主要原
因：
①、多线程并发访问，Linux 是多任务(线程)的系统，所以多线程访问是最基本的原因。
②、抢占式并发访问，从 2.6 版本内核开始，Linux 内核支持抢占，也就是说调度程序可以
在任意时刻抢占正在运行的线程，从而运行其他的线程。
③、中断程序并发访问，这个无需多说，学过 STM32 的同学应该知道，硬件中断的权利可
是很大的。
④、SMP(多核)核间并发访问，现在 ARM 架构的多核 SOC 很常见，多核 CPU 存在核间并
发访问。

三、原子操作

原子操作介绍以及为什么需要竞争保护

所谓的原子操作就是不可再分割的最小操作步骤。
例如c代码：a = 3；这句汇编之后会变成3步骤：
1 ldr r0**, =0X30000000 /* 变量 a 地址 */
2 ldr r1, =3/* 要写入的值 */
3 str r1, **r0**** /* 将 3 写入到 a 变量中 */
例如线程A执行a = 3;而线程B执行b = 20;理想的执行流程如下，互不干涉：

但是上述线程A B代码不加保护的话，实际执行流程可能如下：

原子整形操作API

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

175 typedef struct {
176     int counter;
177 } atomic_t;

如果要使用原子操作 API 函数，首先要先定义一个 atomic_t 的变量，如下所示：
atomic_t a; //定义 a
也可以在定义原子变量的时候给原子变量赋初值，如下所示：
atomic_t b = ATOMIC_INIT(0); //定义原子变量 b 并赋初值为 0

如果使用 64 位的 SOC 的话，就要用到 64 位的原子变量：
typedefstruct {
long long counter**;**
}atomic64_t;

原子位操作API

四、自旋锁

自旋锁介绍

当一个线程要访问某个共享资源的时候首先要先获取相应的锁，锁只能被一个线程持有，
只要此线程不释放持有的锁，那么其他的线程就不能获取此锁。对于自旋锁而言，如果自旋锁
正在被线程 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函数

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

中断插入

如果此时中断也要插一脚，中断也想
访问共享资源，那该怎么办呢？首先可以肯定的是，中断里面可以使用自旋锁，但是在中断里
面使用自旋锁的时候，在获取锁之前一定要先禁止本地中断(也就是本 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)也会竞争共享资源，有些资料也会将下半部叫做底半部。关于下半部后面的
章节会讲解，如果要在下半部里面使用自旋锁

读写自旋锁

只需要保证在
修改此表的时候没人读取，或者在其他人读取此表的时候没有人修改此表就行了。也就是此表
的读和写不能同时进行，但是可以多人并发的读取此表。像这样，当某个数据结构符合读/写或
生产者/消费者模型的时候就可以使用读写自旋锁。
读写自旋锁为读和写操作提供了不同的锁，一次只能允许一个写操作，也就是只能一个线
程持有写锁，而且不能进行读操作。但是当没有写操作的时候允许一个或多个线程持有读锁，
可以进行并发的读操作。Linux 内核使用 rwlock_t 结构体表示读写锁，结构体定义如下(删除了
条件编译)：

typedef struct {
     arch_rwlock_t raw_lock;
} rwlock_t;

顺序锁

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

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

总结

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

信号量

①、因为信号量可以使等待资源线程进入休眠状态，因此适用于那些占用资源比较久的场
合。
②、因此信号量不能用于中断中，因为信号量会引起休眠，中断不能休眠。
③、如果共享资源的持有时间比较短，那就不适合使用信号量了，因为频繁的休眠、切换
线程引起的开销要远大于信号量带来的那点优势。
struct semaphore {
raw_spinlock_t lock**;**
unsigned int count**;**
struct list_head wait_list**;**
};

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

互斥体

虽然可以通过信号量实现互斥，但是 Linux 提供了一个比信号量更专业的机制来进行
互斥，它就是互斥体---mutex。互斥访问表示一次只有一个线程可以访问共享资源，不能递归申
请互斥体。在我们编写 Linux 驱动的时候遇到需要互斥访问的地方建议使用 mutex。Linux 内核
使用 mutex 结构体表示互斥体，定义如下(省略条件编译部分)：
struct mutex {
/* 1: unlocked, 0: locked, negative: locked, possible waiters */
atomic_t count**;**
spinlock_t wait_lock**;**
};
在使用 mutex 之前要先定义一个 mutex 变量。在使用 mutex 的时候要注意如下几点：
①、mutex 可以导致休眠，因此不能在中断中使用 mutex，中断中只能使用自旋锁。
②、和信号量一样，mutex 保护的临界区可以调用引起阻塞的 API 函数。
③、因为一次只有一个线程可以持有 mutex，因此，必须由 mutex 的持有者释放 mutex。并
且 mutex 不能递归上锁和解锁。

互斥体变量使用：

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