Linux 并发与竞争

Linux 并发与竞争

值得一谈，本章与前公司裸机开发的项目中，需要考虑的共用内存的干涉的问题类似，主要针对全局变量在多个中断Level中都会进行读写操作时，需要进行排他处理。需要分析上层任务和下层任务的读写关系，决定是否需要有排他处理的操作，一般采用的排他处理是中断禁止/许可。以Cortex -A7为例，中断禁止的方式为CPSR的bit6和bit7置1。另外，需要考虑以下问题：
①中断禁止的区间，是否过长，过长是否会影响到下个中断的执行，原则上禁止延迟两个中断的执行时间，若超过认为是NG。
②中断禁止的Level，可以通过中断的某个寄存器进行配置，写入level号时，只会禁止比其优先级低的中断等级，因此，原则上仅禁止有影响的中断level，具体需要分析到该全局变量会被调用的最高优先级的中断处理函数，判定中断level，然后才能禁止。
③中断禁止/许可的时机需要进行确认，原则上，需要保证全局变量的同期性，不能随用随禁，需要具体情况具体分析，一般是整体禁止。

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

Linux 系统是个多任务操作系统，会存在多个任务同时访问同一片内存区域，这些任务可能会相互覆盖这段内存中的数据，造成内存数据混乱。针对这个问题必须要做处理，严重的话可能会导致系统崩溃。

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

如何解决并发和竞争带来的问题呢，有如下几种处理方式。

2、原子操作
Linux 内核定义了叫做 atomic_t 的结构体来完成整形数据的原子操作，在使用中用原子变量来代替整形变量。

typedef struct {
	int counter;
} atomic_t;

Linux 内核提供了下列原子操作 API 函数：

原子操作是在驱动的init函数中初始化原子变量的值，在open函数中判断原子变量的值，如果被占用，原子变量的值为0，那么其他线程无法调用open函数，实现了防止并发。

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

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

自旋锁 API 函数

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

线程 A 先运行，并且获取到了 lock 这个锁，当线程 A 运行 functionA 函数的时候中断发生了，中断抢走了 CPU 使用权。右边的中断服务函数也要获取 lock 这个锁，但是这个锁被线程 A 占有着，中断就会一直自旋，等待锁有效。
最好的解决方法就是获取锁之前关闭本地中断，Linux 内核提供了相应的 API 函数

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

由于自旋锁持有的时间不能太长，首先我们定义一个flag，用于判定自旋锁是否已经被占用。在修改这个全局变量flag之前，进行上锁，修改完成后，进行解锁。类似于RAM干涉。

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

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

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

要想使用信号量就得先定义，然后初始化信号量。

信号量的使用和自旋锁类似，但是使用场景不一样。
存疑，信号量的加一减一如何实现的，API函数是哪个？
->信号量和互斥体只会使线程进入休眠状态。上一个线程结束后，该线程会自动执行

5、互斥体(类似于二值信号量)
将信号量的值设置为 1 就可以使用信号量进行互斥访问了，但是 Linux 提供了一个比信号量更专业的机制来进行互斥，它就是互斥体—mutex。(没有用到，不展开)