目录
一、并发与竞争
Linux系统是个多任务操作系统，会存在多个任务同时访问同一片内存区域，也就会出现竞争，这些任务可能会相互覆盖这段内存中的数据，造成内存数据混乱。针对这个问题必须要做处理，严重的话可能会导致系统崩溃。现在的 Linux系统并发产生的原因很复杂，总结一下有下面几个主要原因：
①、多线程并发访问， Linux是多任务 (线程 )的系统，所以多线程 访问是最基本的因。
②、抢占式并发访问，从 2.6版本内核开始， Linux内核支持抢占，也就是说调度程 序可以在任意时刻抢占正在运行的线程，从而运行其他的线程。
③、中断程序并发访问，这个无需多说，学过 STM32的同学应该知道，硬件中断的权利可是很大的。
④、 SMP(多核 )核间并发访问，现在 ARM架构的多核 SOC很常见，多核 CPU存在核间并发访问。
二、共享资源保护
为了保护共享资源，Linux内核提供了几种并发与竞争的处理方法
1、原子操作
原子操作就是指不能再进一步分割的操作 ，一般原子操作用于变量或者位操作
1、原子整形操作API函数
Linux 内核定义了叫做atomic_t 的结构体来完成整形数据的原子操作，在使用中用原子变量来代替整形变量，此结构体定义在 include/linux/types.h 文件中
typedef struct {
int counter;
} atomic_t;
/*针对64位的整形变量*/
typedef struct {
long long counter;
} atomic64_t;原子变量有了，接下来就是对原子变量进行操作，比如读、写、增加、减少等等， Linux内核提供了大量的原子操作 API函数，如下表：
2、原子位操作API函数
位操作也是很常用的操作， Linux内核也提供了一系列的原子位操作 API函数，只不过原子位操作不像原子整形变量那样有个 atomic_t的数据结构，原子位操作是直接对内存进行操作
2、自旋锁
原子操作只能对整形变量或者位进行保护，但是，在实际的使用环境中怎么可能只有整形变量或位这么简单的临界区。对于复杂的结构体数据原子操作就不能胜任了，就需要用到Linux内核中的锁机制。
当一个线程要访问某个 共享资源 的时候首先要先获取相应的锁， 锁只能被一个线程持有，只要此线程不释放持有的锁，那么其他的线程就不能获取此锁。对于自旋锁而言，如果自旋锁正在被线程 A持有，线程B想要获取自旋锁，那么线程 B就会处于忙循环 -旋转 -等待状态，线程 B不会进入休眠状态或者说去做其他的处理，而是会一直傻傻的在那里“转圈圈”的等待锁可用。自旋锁的“自旋”也就是“原地打转”的意思，“原地打转”的目的是为了等待自旋锁可以用，可以访问共享资源。从这里我们可以看到自旋锁的一个缺点：那就等待自旋锁的线程会一直处于自旋状态，这样会浪费处理器时间，降低系统性能，所以自旋锁的持有时间不能太长。所以自旋锁适用于短时期的轻量级加锁，如果遇到需要长时间持有锁的场景那就需要换其他的方法了。
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;1、自旋锁API函数
2、自旋转死锁
上表中的API 函数用于线程之间的并发访问，如果此时中断也要插一脚，中断也想访问共享资源，那该怎么办呢？首先可以肯定的是，中断里面可以使用自旋锁，但是在中断里面使用自旋锁的时候，在获取锁之前一定要先禁止本地中断(也就是本CPU 中断，对于多核SOC来说会有多个CPU 核)，否则可能导致锁死现象的发生
线程A 先运行，并且获取到了lock 这个锁，当线程A 运行functionA 函数的时候中断发生了，中断抢走了CPU 使用权。右边的中断服务函数也要获取lock 这个锁，但是这个锁被线程A 占有着，中断就会一直自旋，等待锁有效。但是在中断服务函数执行完之前，线程 A是不可能执行的，线程 A说“你先放手”，中断说“你先放手”，场面就这么僵持着，死锁发生！最好的解决方法就是获取锁之前关闭本地中断， Linux内核提供了相应的 API函数，如下表。一般在线程中使用 spin_lock_irqsave/ spin_unlock_irqrestore，在中断中使用 spin_lock/spin_unlock
3、自旋锁注意事项
①、因为在等待自旋锁的时候处于“自旋”状态，因此锁的持有时间不能太长，一定要短，否则的话会降低系统性能。如果临界区比较大，运行时间比较长的话要选择其他的并发处理方式，比如稍后要讲的信号量和互斥体。
②、自旋锁保护的临界区内不能调用任何可能导致线程休眠的 API函数，否则的话可能导致 死锁。
③、不能递归申请自旋锁，因为一旦通过递归的方式申请一个你正在持有的锁，那么你就必须“自旋”， 等待锁被释放，然而你正处于“自旋”状态，根本没法释放锁。结果就是自己把自己锁死了！
④、在编写驱动程序的时候我们必须考虑到驱动的可移植性，因此不管你用的是单核的还是多核的 SOC，都将其当做多核 SOC来编写驱动程序。
3、信号量
1、信号量特点
①、因为信号量可以使等待资源线程进入休眠状态，因此适用于那些占用资源比较久的场合。
②、因此信号量不能用于中断中，因为信号量会引起休眠，中断不能休眠。
③、如果共享资源的持有时间比较短，那就不适合使用信号量了，因为频繁的休眠、切换线程引起的开 销要远大于信号量带来的那点优势。
2、信号量API函数
Linux内核使用 semaphore结构体表示信号量，结构体内容如下所示：
struct semaphore {
raw_spinlock_t lock;
unsigned int count;
struct list_head wait_list;
};
4、互斥体
1、互斥体特点
将信号量的值设置为 1就可以使用信号量进行互斥访问了，虽然可以通过信号量实现互斥，但是 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不能递归上锁和解锁。
