一、并发与竞争

        Linux是一个多任务操作系统,肯定会存在多个任务共同操作同一段内存或者设备的情况,多个任务甚至中断都能访问的资源叫做共享资源,就和共享单车一样。在驱动开发中要注意对共享资源的保护,也就是要处理对共享资源的并发访问。

        并发就是多个“用户”同时访问同一个共享资源。

        这里举一个例子:你们公司有一台打印机,你们公司的所有人都可以使用。现在小李和小王要同时使用这一台打印机,都要打印一份文件。

寅程要打印的文件内容如下:

我叫寅程
电话: 123456
工号:10

小熊要打印的文件内容如下:

我叫小熊
电话:654321
工号:11

        这两份文档肯定是各自打印出来的,不能相互影响。当两个人同时打印的话如果打印机不做处 理的话可能会出现寅程的文档打印了一行,然后开始打印小熊的文档,这样打印出来的文档就错乱了,可能会出现如下的错误文档内容:

我叫寅程
电话:654321
工号:10

        可以看出寅程的电话变成了小熊的电话,这是绝对不允许出现的操作。如果有多人同时向打印机发送了多份文档,打印机必须保证一次只能打印一份文档,只有打印完成以后才能打印其他的文档。

        Linux 系统是个多任务操作系统,会存在多个任务同时访问同一片内存区域,这些任务可能会相互覆盖这段内存中的数据,造成内存数据混乱。针对这个问题必须要做处理,严重的话可能会导致系统崩溃。现在的 Linux 系统并发产生的原因很复杂,总结一下有下面几个主要原因:

        ①多线程并发访问,Linux 是多任务(线程)的系统,所以多线程访问是最基本的原因。

        ②抢占式并发访问,从 2.6 版本内核开始,Linux 内核支持抢占,也就是说调度程序可以在任意时刻抢占正在运行的线程,从而运行其他的线程。

        ③中断程序并发访问,这个无需多说,学过 STM32 的同学应该知道,硬件中断的权利可是很大的。

        ④SMP(多核)核间并发访问,现在 ARM 架构的多核 SOC 很常见,多核 CPU 存在核间并发访问。

        并发访问带来的问题就是竞争,所谓的临界区就是共享数据段,对于临界区必须保证一次只有一个线程访问,也就是要保证临界区是原子访问的。

        提示:这里的原子操作可以理解为化学反应中的基本微粒——原子,这里的原子访问就表示这一个访问是一个步骤,不能再进行拆分。

        如果多个线程同时操作临界区就表示存在竞争,我们在编写驱动的时候一定要注意避免并发和防止竞争访问。

        当我们发现驱动程序中存在并发和竞争的时候一定要处理掉,接下来我们依次来学习一下Linux 内核提供的几种并发和竞争的处理方法。

二、处理并发与竞争的几种常见方法

一、原子操作

        原子操作就是指不能再进一步分割的操作,一般原子操作用于变量或者位操作。假如现在要对无符号整形变量 a 赋值,值为 3,对于 C 语言来讲很简单,直接就是:

    a = 3

    但是 C 语言要先编译为成汇编指令,ARM 架构不支持直接对寄存器进行读写操作,比如要借助寄存器 R0、R1 等来完成赋值操作。

        假设现在线程 A要向 a 变量写入 10 这个值,而线程 B 也要向 a 变量写入 20 这个值。则有可能出现汇编情况如下:

         线程 A 最终将变量 a 设置为了 20,而并不是要求的 10!线程B 没有问题,这就是一个最简单的设置变量值的并发与竞争的例子。

        Linux 内核提供了一组原子操作 API 函数来完成此功能,Linux 内核提供了两组原子操作 API 函数,一组是对整形变量进行操作的,一组是对位进行操作的,我们接下来看一下这些 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

        原子变量有了,接下来就是对原子变量进行操作,比如读、写、增加、减少等等,Linux 内核提供了大量的原子操作 API 函数,如下图所示:

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

typedef struct {
    long long counter;
} atomic64_t;

      API 函数有用法一样,只是将“atomic_”前缀换为“atomic64_”,将 int 换为 long long。如果使用的是 64 位的 SOC,那么就要使用 64 位的原子操作函数。

        原子变量和相应的 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 */

二、自旋锁

        自旋锁简介

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

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

        自旋锁的“自旋”也就是“原地打转”的意思,“原地打转”的目的是为了等待自旋锁可以用,可以访问共享资源。把自旋锁比作一个变量 a,变量 a=1 的时候表示共享资源可用,当 a=0的时候表示共享资源不可用。现在线程 A 要访问共享资源,发现 a=0(自旋锁被其他线程持有),那么线程 A 就会不断的查询 a 的值,直到 a=1。

        从这里我们可以看到自旋锁的一个缺点:那就等待自旋锁的线程会一直处于自旋状态,这样会浪费处理器时间,降低系统性能,所以自旋锁的持有时间不能太长。所以自旋锁适用于短时期的轻量级加锁,如果遇到需要长时间持有锁的场景那就需要换其他的方法了。

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

typedef struct spinlock {
union {
struct raw_spinlock rlock;
 
#ifdef CONFIG_DEBUG_LOCK_ALLOC
# define LOCK_PADSIZE (offsetof(struct raw_spinlock, dep_map))
 
    struct {
    u8 __padding[LOCK_PADSIZE];
    struct lockdep_map dep_map;
    };
#endif
};
} spinlock_t;

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

    spinlock_t lock;     //定义自旋锁

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

        自旋锁 API 函数

        最基本的自旋锁 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,因为这一组函数会保存中断状态,在释放锁的时候会恢复中断状态。

        一般在线程中使用 spin_lock_irqsave/spin_unlock_irqrestore,在中断中使用spin_lock/spin_unlock,示例代码如下所示:

        下半部(BH)也会竞争共享资源,有些资料也会将下半部叫做底半部。如果要在下半部里面使用自旋锁,可以使用表中的 API 函数:

其他类型的锁

        在自旋锁的基础上还衍生出了其他特定场合使用的锁,这些锁在驱动中其实用的不多,更多的是在 Linux 内核中使用,比如(1)读写自旋锁;(2)顺序锁

自旋锁使用注意事项

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

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

        为了更好的阅读体验,关于信号量和互斥体部分,将放在下一章节进行讲解。