spinlocklinux
Ⅰ 关于linux自旋锁
既然是对一个变量进行保护，当然是一个自旋锁了，还没见过一个变量能当两个用的。
我觉得你对这段代码的理解有问题，用 spin_lock 和 spin_unlock 的目的是保证程序在对 xxx_lock 进行操作的时候，不会有其它进程改变这个值，是为了保证数据的准确性。
你可以设想一下，如果没有自旋锁，代码运行起来会有什么问题。假设 A,B两个进程同时访问 open ， 没有使用自旋锁，此时 xxx_lock=0, A 进程在判断 if (xxx_count) 时，会认为设备没有被使用，那么它会继续后面的 xxx_count++ 操作，但假如这时 CPU 切换进程， A 进程还没有来得及把 xxx_count 变成 1 的时候， B 进程开始运行，那么 B 进程此时也会认为设备没有被使用，它也会进行后继操作，这样就会出现两个进程同时访问设备的错误。
open 和 release 当然可以同时访问，只不过在运行 spin_lock 的时候，后访问的进程会被阻塞而已。假设有 A 进程访问 open ，B 进程访问 release ，你可以把这种情况理解为 A ， B 进程同时访问 open 函数，这样或许能更好的理解这段代码。因为 open 和 release 在使用自旋锁的时候，方法是一样的。
spin_lock 和 CPU 系统无关，不管是单 CPU 还是多 CPU ，运行结果都是一样的。
这个逻辑关系比较难解释，不知道你看懂我的意思没。
Ⅱ 如何使用spinlock要哪个头文件
在kernel2.4.20下面：
include <linux/spinlock.h>
spinlock_t mysiglock = SPIN_LOCK_UNLOCKED;
unsigned int flags;
然后：
spin_lock_irqsave(&mysiglock,flags);
spin_unlock_irqrestore(&mysiglock,flags);
可以编译，但连接的时候kernel.o时说：
undefined reference to 'local_irq_save'
Ⅲ linux原子操作和自旋锁的区别
现代操作系统支持多任务的并发，并发在提高计算资源利用率的同时也带来了资源竞争的问题。例如C语言语句“count++;”在未经编译器优化时生成的汇编代码为。
当操作系统内存在多个进程同时执行这段代码时，就可能带来并发问题。
假设count变量初始值为0。进程1执行完“mov eax, [count]”后，寄存器eax内保存了count的值0。此时，进程2被调度执行，抢占了进程1的CPU的控制权。进程2执行“count++;”的汇编代码，将累加后的count值1写回到内存。然后，进程1再次被调度执行，CPU控制权回到进程1。进程1接着执行，计算count的累加值仍为1，写回到内存。虽然进程1和进程2执行了两次“count++;”操作，但是count实际的内存值为1，而不是2！
单处理器原子操作
解决这个问题的方法是，将“count++;”语句翻译为单指令操作。
Intel x86指令集支持内存操作数的inc操作，这样“count++;”操作可以在一条指令内完成。因为进程的上下文切换是在总是在一条指令执行完成后，所以不会出现上述的并发问题。对于单处理器来说，一条处理器指令就是一个原子操作。
多处理器原子操作
但是在多处理器的环境下，例如SMP架构，这个结论不再成立。我们知道“inc [count]”指令的执行过程分为三步：
1）从内存将count的数据读取到cpu。
2）累加读取的值。
3）将修改的值写回count内存。
这又回到前面并发问题类似的情况，只不过此时并发的主题不再是进程，而是处理器。
Intel x86指令集提供了指令前缀lock用于锁定前端串行总线（FSB），保证了指令执行时不会受到其他处理器的干扰。
使用lock指令前缀后，处理器间对count内存的并发访问（读/写）被禁止，从而保证了指令的原子性。
x86原子操作实现
Linux的源码中x86体系结构原子操作的定义文件为。
linux2.6/include/asm-i386/atomic.h
文件内定义了原子类型atomic_t，其仅有一个字段counter，用于保存32位的数据。
typedef struct { volatile int counter; } atomic_t;
其中原子操作函数atomic_inc完成自加原子操作。
/**
* atomic_inc - increment atomic variable
* @v: pointer of type atomic_t
*
* Atomically increments @v by 1.
*/
static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__(
LOCK "incl %0"
:"=m" (v->counter)
:"m" (v->counter));
}
其中LOCK宏的定义为。
#ifdef CONFIG_SMP
#define LOCK "lock ; "
#else
#define LOCK ""
#endif
可见，在对称多处理器架构的情况下，LOCK被解释为指令前缀lock。而对于单处理器架构，LOCK不包含任何内容。
arm原子操作实现
在arm的指令集中，不存在指令前缀lock，那如何完成原子操作呢？
Linux的源码中arm体系结构原子操作的定义文件为。
linux2.6/include/asm-arm/atomic.h
其中自加原子操作由函数atomic_add_return实现。
static inline int atomic_add_return(int i, atomic_t *v)
{
unsigned long tmp;
int result;
__asm__ __volatile__("@ atomic_add_return\n"
"1: ldrex %0, [%2]\n"
" add %0, %0, %3\n"
" strex %1, %0, [%2]\n"
" teq %1, #0\n"
" bne 1b"
: "=&r" (result), "=&r" (tmp)
: "r" (&v->counter), "Ir" (i)
: "cc");
return result;
}
上述嵌入式汇编的实际形式为。
1:
ldrex [result], [v->counter]
add [result], [result], [i]
strex [temp], [result], [v->counter]
teq [temp], #0
bne 1b
ldrex指令将v->counter的值传送到result，并设置全局标记“Exclusive”。
add指令完成“result+i”的操作，并将加法结果保存到result。
strex指令首先检测全局标记“Exclusive”是否存在，如果存在，则将result的值写回counter->v，并将temp置为0，清除“Exclusive”标记，否则直接将temp置为1结束。
teq指令测试temp值是否为0。
bne指令temp不等于0时跳转到标号1，其中字符b表示向后跳转。
整体看来，上述汇编代码一直尝试完成“v->counter+=i”的操作，直到temp为0时结束。
使用ldrex和strex指令对是否可以保证add指令的原子性呢？假设两个进程并发执行“ldrex+add+strex”操作，当进程1执行ldrex后设定了全局标记“Exclusive”。此时切换到进程2，执行ldrex前全局标记“Exclusive”已经设定，ldrex执行后重复设定了该标记。然后执行add和strex指令，完成累加操作。再次切换回进程1，接着执行add指令，当执行strex指令时，由于“Exclusive”标记被进程2清除，因此不执行传送操作，将temp设置为1。后继teq指令测定temp不等于0，则跳转到起始位置重新执行，最终完成累加操作！可见ldrex和strex指令对可以保证进程间的同步。多处理器的情况与此相同，因为arm的原子操作只关心“Exclusive”标记，而不在乎前端串行总线是否加锁。
在ARMv6之前，swp指令就是通过锁定总线的方式完成原子的数据交换，但是影响系统性能。ARMv6之后，一般使用ldrex和strex指令对代替swp指令的功能。
自旋锁中的原子操作
Linux的源码中x86体系结构自旋锁的定义文件为。
linux2.6/include/asm-i386/spinlock.h
其中__raw_spin_lock完成自旋锁的加锁功能
#define __raw_spin_lock_string \
"\n1:\t" \
"lock ; decb %0\n\t" \
"jns 3f\n" \
"2:\t" \
"rep;nop\n\t" \
"cmpb $0,%0\n\t" \
"jle 2b\n\t" \
"jmp 1b\n" \
"3:\n\t"
static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
__asm__ __volatile__(
__raw_spin_lock_string
:"=m" (lock->slock) : : "memory");
}
上述代码的实际汇编形式为。
1：
lock decb [lock->slock]
jns 3
2:
rep nop
cmpb $0, [lock->slock]
jle 2
jmp 1
3:
其中lock->slock字段初始值为1，执行原子操作decb后值为0。符号位为0，执行jns指令跳转到3，完成自旋锁的加锁。
当再次申请自旋锁时，执行原子操作decb后lock->slock值为-1。符号位为1，不执行jns指令。进入标签2，执行一组nop指令后比较lock->slock是否小于等于0，如果小于等于0回到标签2进行循环（自旋）。否则跳转到标签1重新申请自旋锁，直到申请成功。
自旋锁释放时会将lock->slock设置为1，这样保证了其他进程可以获得自旋锁。
信号量中的原子操作
Linux的源码中x86体系结构自旋锁的定义文件为。
linux2.6/include/asm-i386/semaphore.h
信号量的申请操作由函数down实现。
/*
* This is ugly, but we want the default case to fall through.
* "__down_failed" is a special asm handler that calls the C
* routine that actually waits. See arch/i386/kernel/semaphore.c
*/
static inline void down(struct semaphore * sem)
{
might_sleep();
__asm__ __volatile__(
"# atomic down operation\n\t"
LOCK "decl %0\n\t" /* --sem->count */
"js 2f\n"
"1:\n"
LOCK_SECTION_START("")
"2:\tlea %0,%%eax\n\t"
"call __down_failed\n\t"
"jmp 1b\n"
LOCK_SECTION_END
:"=m" (sem->count)
:
:"memory","ax");
}
实际的汇编代码形式为。
lock decl [sem->count]
js 2
1:
<========== another section ==========>
2:
lea [sem->count], eax
call __down_failed
jmp 1
信号量的sem->count一般初始化为一个正整数，申请信号量时执行原子操作decl，将sem->count减1。如果该值减为负数（符号位为1）则跳转到另一个段内的标签2，否则申请信号量成功。
标签2被编译到另一个段内，进入标签2后，执行lea指令取出sem->count的地址，放到eax寄存器作为参数，然后调用函数__down_failed表示信号量申请失败，进程加入等待队列。最后跳回标签1结束信号量申请。
信号量的释放操作由函数up实现。
/*
* Note! This is subtle. We jump to wake people up only if
* the semaphore was negative (== somebody was waiting on it).
* The default case (no contention) will result in NO
* jumps for both down() and up().
*/
static inline void up(struct semaphore * sem)
{
__asm__ __volatile__(
"# atomic up operation\n\t"
LOCK "incl %0\n\t" /* ++sem->count */
"jle 2f\n"
"1:\n"
LOCK_SECTION_START("")
"2:\tlea %0,%%eax\n\t"
"call __up_wakeup\n\t"
"jmp 1b\n"
LOCK_SECTION_END
".subsection 0\n"
:"=m" (sem->count)
:
:"memory","ax");
}
实际的汇编代码形式为。
lock incl sem->count
jle 2
1:
<========== another section ==========>
2:
lea [sem->count], eax
call __up_wakeup
jmp 1
释放信号量时执行原子操作incl将sem->count加1，如果该值小于等于0，则说明等待队列有阻塞的进程需要唤醒，跳转到标签2，否则信号量释放成功。
标签2被编译到另一个段内，进入标签2后，执行lea指令取出sem->count的地址，放到eax寄存器作为参数，然后调用函数__up_wakeup唤醒等待队列的进程。最后跳回标签1结束信号量释放。
Ⅳ linux内核同步问题
Linux内核设计与实现 十、内核同步方法
手把手教Linux驱动5-自旋锁、信号量、互斥体概述
== 基础概念： ==
并发 ：多个执行单元同时进行或多个执行单元微观串行执行，宏观并行执行
竞态 ：并发的执行单元对共享资源（硬件资源和软件上的全局变量）的访问而导致的竟态状态。
临界资源 ：多个进程访问的资源
临界区 ：多个进程访问的代码段
== 并发场合： ==
1、单CPU之间进程间的并发 :时间片轮转，调度进程。 A进程访问打印机，时间片用完，OS调度B进程访问打印机。
2、单cpu上进程和中断之间并发 ：CPU必须停止当前进程的执行中断;
3、多cpu之间
4、单CPU上中断之间的并发
== 使用偏向： ==
==信号量用于进程之间的同步，进程在信号量保护的临界区代码里面是可以睡眠的（需要进行进程调度），这是与自旋锁最大的区别。==
信号量又称为信号灯，它是用来协调不同进程间的数据对象的，而最主要的应用是共享内存方式的进程间通信。本质上，信号量是一个计数器，它用来记录对某个资源（如共享内存）的存取状况。它负责协调各个进程，以保证他们能够正确、合理的使用公共资源。它和spin lock最大的不同之处就是：无法获取信号量的进程可以睡眠，因此会导致系统调度。
1、==用于进程与进程之间的同步==
2、==允许多个进程进入临界区代码执行，临界区代码允许睡眠；==
3、信号量本质是==基于调度器的==，在UP和SMP下没有区别；进程获取不到信号量将陷入休眠，并让出CPU；
4、不支持进程和中断之间的同步
5、==进程调度也是会消耗系统资源的，如果一个int型共享变量就需要使用信号量，将极大的浪费系统资源==
6、信号量可以用于多个线程，用于资源的计数（有多种状态）
==信号量加锁以及解锁过程：==
sema_init(&sp->dead_sem, 0); / 初始化 /
down(&sema);
临界区代码
up(&sema);
==信号量定义：==
==信号量初始化：==
==dowm函数实现：==
==up函数实现：==
信号量一般可以用来标记可用资源的个数。
举2个生活中的例子：
==dowm函数实现原理解析：==
（1）down
判断sem->count是否 > 0，大于0则说明系统资源够用，分配一个给该进程，否则进入__down(sem);
（2）__down
调用__down_common(sem, TASK_UNINTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);其中TASK_UNINTERRUPTIBLE=2代表进入睡眠，且不可以打断；MAX_SCHEDULE_TIMEOUT休眠最长LONG_MAX时间；
（3）list_add_tail(&waiter.list, &sem->wait_list);
把当前进程加入到sem->wait_list中；
（3）先解锁后加锁;
进入__down_common前已经加锁了，先把解锁，调用schele_timeout(timeout)，当waiter.up=1后跳出for循环；退出函数之前再加锁；
Linux内核ARM构架中原子变量的底层实现研究
rk3288 原子操作和原子位操作
原子变量适用于只共享一个int型变量；
1、原子操作是指不被打断的操作，即它是最小的执行单位。
2、最简单的原子操作就是一条条的汇编指令(不包括一些伪指令，伪指令会被汇编器解释成多条汇编指令)
==常见函数：==
==以atomic_inc为例介绍实现过程==
在Linux内核文件archarmincludeasmatomic.h中。 执行atomic_read、atomic_set这些操作都只需要一条汇编指令，所以它们本身就是不可打断的。 需要特别研究的是atomic_inc、atomic_dec这类读出、修改、写回的函数。
所以atomic_add的原型是下面这个宏：
atomic_add等效于：
result（%0） tmp（%1） (v->counter)（%2） (&v->counter)（%3） i（%4）
注意：根据内联汇编的语法，result、tmp、&v->counter对应的数据都放在了寄存器中操作。如果出现上下文切换，切换机制会做寄存器上下文保护。
（1）ldrex %0, [%3]
意思是将&v->counter指向的数据放入result中，并且（分别在Local monitor和Global monitor中）设置独占标志。
（2）add %0, %0, %4
result = result + i
（3）strex %1, %0, [%3]
意思是将result保存到&v->counter指向的内存中， 此时 Exclusive monitors会发挥作用，将保存是否成功的标志放入tmp中。
（4） teq %1, #0
测试strex是否成功（tmp == 0 ？？）
（5）bne 1b
如果发现strex失败，从（1）再次执行。
Spinlock 是内核中提供的一种比较常见的锁机制，==自旋锁是“原地等待”的方式解决资源冲突的==，即，一个线程获取了一个自旋锁后，另外一个线程期望获取该自旋锁，获取不到，只能够原地“打转”（忙等待）。由于自旋锁的这个忙等待的特性，注定了它使用场景上的限制 —— 自旋锁不应该被长时间的持有（消耗 CPU 资源），一般应用在==中断上下文==。
1、spinlock是一种死等机制
2、信号量可以允许多个执行单元进入，spinlock不行，一次只能允许一个执行单元获取锁，并且进入临界区，其他执行单元都是在门口不断的死等
3、由于不休眠，因此spinlock可以应用在中断上下文中；
4、由于spinlock死等的特性，因此临界区执行代码尽可能的短；
==spinlock加锁以及解锁过程：==
spin_lock(&devices_lock);
临界区代码
spin_unlock(&devices_lock);
==spinlock初始化==
==进程和进程之间同步==
==本地软中断之间同步==
==本地硬中断之间同步==
==本地硬中断之间同步并且保存本地中断状态==
==尝试获取锁==
== arch_spinlock_t结构体定义如下： ==
== arch_spin_lock的实现如下： ==
lockval（%0） newval（%1） tmp（%2） &lock->slock（%3） 1 << TICKET_SHIFT（%4）
（1）ldrex %0, [%3]
把lock->slock的值赋值给lockval；并且（分别在Local monitor和Global monitor中）设置独占标志。
（2）add %1, %0, %4
newval =lockval +（1<<16）; 相当于next+1；
（3）strex %2, %1, [%3]
newval =lockval +（1<<16）; 相当于next+1；
意思是将newval保存到 &lock->slock指向的内存中， 此时 Exclusive monitors会发挥作用，将保存是否成功的标志放入tmp中。
（4） teq %2, #0
测试strex是否成功
（5）bne 1b
如果发现strex失败，从（1）再次执行。
通过上面的分析，可知关键在于strex的操作是否成功的判断上。而这个就归功于ARM的Exclusive monitors和ldrex/strex指令的机制。
（6）while (lockval.tickets.next != lockval.tickets.owner)
如何lockval.tickets的next和owner是否相等。相同则跳出while循环，否则在循环内等待判断；
* （7）wfe()和smp_mb() 最终调用#define barrier() asm volatile ("": : :"memory") *
阻止编译器重排，保证编译程序时在优化屏障之前的指令不会在优化屏障之后执行。
== arch_spin_unlock的实现如下： ==
退出锁时：tickets.owner++
== 出现死锁的情况： ==
1、拥有自旋锁的进程A在内核态阻塞了，内核调度B进程，碰巧B进程也要获得自旋锁，此时B只能自旋转。 而此时抢占已经关闭，（单核）不会调度A进程了，B永远自旋，产生死锁。
2、进程A拥有自旋锁，中断到来，CPU执行中断函数，中断处理函数，中断处理函数需要获得自旋锁，访问共享资源，此时无法获得锁，只能自旋，产生死锁。
== 如何避免死锁： ==
1、如果中断处理函数中也要获得自旋锁，那么驱动程序需要在拥有自旋锁时禁止中断；
2、自旋锁必须在可能的最短时间内拥有
3、避免某个获得锁的函数调用其他同样试图获取这个锁的函数，否则代码就会死锁；不论是信号量还是自旋锁，都不允许锁拥有者第二次获得这个锁，如果试图这么做，系统将挂起；
4、锁的顺序规则（a) 按同样的顺序获得锁；b) 如果必须获得一个局部锁和一个属于内核更中心位置的锁，则应该首先获取自己的局部锁 ;c) 如果我们拥有信号量和自旋锁的组合，则必须首先获得信号量；在拥有自旋锁时调用down(可导致休眠)是个严重的错误的；）
== rw（read/write）spinlock： ==
加锁逻辑：
1、假设临界区内没有任何的thread，这个时候任何的读线程和写线程都可以键入
2、假设临界区内有一个读线程，这时候信赖的read线程可以任意进入，但是写线程不能进入；
3、假设临界区有一个写线程，这时候任何的读、写线程都不可以进入；
4、假设临界区内有一个或者多个读线程，写线程不可以进入临界区，但是写线程也无法阻止后续的读线程继续进去，要等到临界区所有的读线程都结束了，才可以进入，可见：==rw（read/write）spinlock更加有利于读线程；==
== seqlock（顺序锁）： ==
加锁逻辑：
1、假设临界区内没有任何的thread，这个时候任何的读线程和写线程都可以键入
2、假设临界区内没有写线程的情况下，read线程可以任意进入；
3、假设临界区有一个写线程，这时候任何的读、写线程都不可以进入；
4、假设临界区内只有read线程的情况下，写线程可以理解执行，不会等待，可见：==seqlock（顺序锁）更加有利于写线程；==
读写速度 ： CPU > 一级缓存 > 二级缓存 > 内存 ，因此某一个CPU0的lock修改了，其他的CPU的lock就会失效；那么其他CPU就会依次去L1 L2和主存中读取lock值，一旦其他CPU去读取了主存，就存在系统性能降低的风险；
mutex用于互斥操作。
互斥体只能用于一个线程，资源只有两种状态（占用或者空闲）
1、mutex的语义相对于信号量要简单轻便一些，在锁争用激烈的测试场景下，mutex比信号量执行速度更快，可扩展
性更好，
2、另外mutex数据结构的定义比信号量小;、
3、同一时刻只有一个线程可以持有mutex
4、不允许递归地加锁和解锁
5、当进程持有mutex时，进程不可以退出。
• mutex必须使用官方API来初始化。
• mutex可以睡眠，所以不允许在中断处理程序或者中断下半部中使用，例如tasklet、定时器等
==常见操作：==
struct mutex mutex_1;
mutex_init(&mutex_1);
mutex_lock(&mutex_1)
临界区代码；
mutex_unlock(&mutex_1)
==常见函数：==
=
Ⅳ 如何实现linux下多线程之间的互斥与同步
Linux设备驱动中必须解决的一个问题是多个进程对共享资源的并发访问，并发访问会导致竞态，linux提供了多种解决竞态问题的方式，这些方式适合不同的应用场景。
Linux内核是多进程、多线程的操作系统，它提供了相当完整的内核同步方法。内核同步方法列表如下：
中断屏蔽
原子操作
自旋锁
读写自旋锁
顺序锁
信号量
读写信号量
BKL（大内核锁）
Seq锁
一、并发与竞态：
定义：
并发（concurrency）指的是多个执行单元同时、并行被执行，而并发的执行单元对共享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions）。
在linux中，主要的竞态发生在如下几种情况：
1、对称多处理器（SMP）多个CPU
特点是多个CPU使用共同的系统总线，因此可访问共同的外设和存储器。
2、单CPU内进程与抢占它的进程
3、中断（硬中断、软中断、Tasklet、底半部）与进程之间
只要并发的多个执行单元存在对共享资源的访问，竞态就有可能发生。
如果中断处理程序访问进程正在访问的资源，则竞态也会会发生。
多个中断之间本身也可能引起并发而导致竞态（中断被更高优先级的中断打断）。
解决竞态问题的途径是保证对共享资源的互斥访问，所谓互斥访问就是指一个执行单元在访问共享资源的时候，其他的执行单元都被禁止访问。
访问共享资源的代码区域被称为临界区，临界区需要以某种互斥机制加以保护，中断屏蔽，原子操作，自旋锁，和信号量都是linux设备驱动中可采用的互斥途径。
临界区和竞争条件：
所谓临界区（critical regions）就是访问和操作共享数据的代码段，为了避免在临界区中并发访问，编程者必须保证这些代码原子地执行——也就是说，代码在执行结束前不可被打断，就如同整个临界区是一个不可分割的指令一样，如果两个执行线程有可能处于同一个临界区中，那么就是程序包含一个bug，如果这种情况发生了，我们就称之为竞争条件（race conditions），避免并发和防止竞争条件被称为同步。
死锁：
死锁的产生需要一定条件：要有一个或多个执行线程和一个或多个资源，每个线程都在等待其中的一个资源，但所有的资源都已经被占用了，所有线程都在相互等待，但它们永远不会释放已经占有的资源，于是任何线程都无法继续，这便意味着死锁的发生。
二、中断屏蔽
在单CPU范围内避免竞态的一种简单方法是在进入临界区之前屏蔽系统的中断。
由于linux内核的进程调度等操作都依赖中断来实现，内核抢占进程之间的并发也就得以避免了。
中断屏蔽的使用方法：
local_irq_disable()//屏蔽中断
//临界区
local_irq_enable()//开中断
特点：
由于linux系统的异步IO，进程调度等很多重要操作都依赖于中断，在屏蔽中断期间所有的中断都无法得到处理，因此长时间的屏蔽是很危险的，有可能造成数据丢失甚至系统崩溃，这就要求在屏蔽中断之后，当前的内核执行路径应当尽快地执行完临界区的代码。
中断屏蔽只能禁止本CPU内的中断，因此，并不能解决多CPU引发的竞态，所以单独使用中断屏蔽并不是一个值得推荐的避免竞态的方法，它一般和自旋锁配合使用。
三、原子操作
定义：原子操作指的是在执行过程中不会被别的代码路径所中断的操作。
（原子原本指的是不可分割的微粒，所以原子操作也就是不能够被分割的指令）
（它保证指令以“原子”的方式执行而不能被打断）
原子操作是不可分割的，在执行完毕不会被任何其它任务或事件中断。在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是" 原子操作"，因为中断只能发生于指令之间。这也是某些CPU指令系统中引入了test_and_set、test_and_clear等指令用于临界资源互斥的原因。但是，在对称多处理器(Symmetric Multi-Processor)结构中就不同了，由于系统中有多个处理器在独立地运行，即使能在单条指令中完成的操作也有可能受到干扰。我们以decl (递减指令)为例，这是一个典型的"读－改－写"过程，涉及两次内存访问。
通俗理解：
原子操作，顾名思义，就是说像原子一样不可再细分。一个操作是原子操作，意思就是说这个操作是以原子的方式被执行，要一口气执行完，执行过程不能够被OS的其他行为打断，是一个整体的过程，在其执行过程中，OS的其它行为是插不进来的。
分类：linux内核提供了一系列函数来实现内核中的原子操作，分为整型原子操作和位原子操作，共同点是：在任何情况下操作都是原子的，内核代码可以安全的调用它们而不被打断。
原子整数操作：
针对整数的原子操作只能对atomic_t类型的数据进行处理，在这里之所以引入了一个特殊的数据类型，而没有直接使用C语言的int型，主要是出于两个原因：
第一、让原子函数只接受atomic_t类型的操作数，可以确保原子操作只与这种特殊类型数据一起使用，同时，这也确保了该类型的数据不会被传递给其它任何非原子函数；
第二、使用atomic_t类型确保编译器不对相应的值进行访问优化——这点使得原子操作最终接收到正确的内存地址，而不是一个别名，最后就是在不同体系结构上实现原子操作的时候，使用atomic_t可以屏蔽其间的差异。
原子整数操作最常见的用途就是实现计数器。
另一点需要说明原子操作只能保证操作是原子的，要么完成，要么不完成，不会有操作一半的可能，但原子操作并不能保证操作的顺序性，即它不能保证两个操作是按某个顺序完成的。如果要保证原子操作的顺序性，请使用内存屏障指令。
atomic_t和ATOMIC_INIT(i)定义
typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }
在你编写代码的时候，能使用原子操作的时候，就尽量不要使用复杂的加锁机制，对多数体系结构来讲，原子操作与更复杂的同步方法相比较，给系统带来的开销小，对高速缓存行的影响也小，但是，对于那些有高性能要求的代码，对多种同步方法进行测试比较，不失为一种明智的作法。
原子位操作：
针对位这一级数据进行操作的函数，是对普通的内存地址进行操作的。它的参数是一个指针和一个位号。
为方便其间，内核还提供了一组与上述操作对应的非原子位函数，非原子位函数与原子位函数的操作完全相同，但是，前者不保证原子性，且其名字前缀多两个下划线。例如，与test_bit()对应的非原子形式是_test_bit()，如果你不需要原子性操作（比如，如果你已经用锁保护了自己的数据），那么这些非原子的位函数相比原子的位函数可能会执行得更快些。
四、自旋锁
自旋锁的引入：
如 果每个临界区都能像增加变量这样简单就好了，可惜现实不是这样，而是临界区可以跨越多个函数，例如：先得从一个数据结果中移出数据，对其进行格式转换和解 析，最后再把它加入到另一个数据结构中，整个执行过程必须是原子的，在数据被更新完毕之前，不能有其他代码读取这些数据，显然，简单的原子操作是无能为力 的（在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是" 原子操作"，因为中断只能发生于指令之间），这就需要使用更为复杂的同步方法——锁来提供保护。
自旋锁的介绍：
Linux内核中最常见的锁是自旋锁（spin lock），自旋锁最多只能被一个可执行线程持有，如果一个执行线程试图获得一个被争用（已经被持有）的自旋锁，那么该线程就会一直进行忙循环—旋转—等待锁重新可用，要是锁未被争用，请求锁的执行线程便能立刻得到它，继续执行，在任意时间，自旋锁都可以防止多于一个的执行线程同时进入理解区，注意同一个锁可以用在多个位置—例如，对于给定数据的所有访问都可以得到保护和同步。
一个被争用的自旋锁使得请求它的线程在等待锁重新可用时自旋（特别浪费处理器时间），所以自旋锁不应该被长时间持有，事实上，这点正是使用自旋锁的初衷，在短期间内进行轻量级加锁，还可以采取另外的方式来处理对锁的争用：让请求线程睡眠，直到锁重新可用时再唤醒它，这样处理器就不必循环等待，可以去执行其他代码，这也会带来一定的开销——这里有两次明显的上下文切换， 被阻塞的线程要换出和换入。因此，持有自旋锁的时间最好小于完成两次上下文切换的耗时，当然我们大多数人不会无聊到去测量上下文切换的耗时，所以我们让持 有自旋锁的时间应尽可能的短就可以了，信号量可以提供上述第二种机制，它使得在发生争用时，等待的线程能投入睡眠，而不是旋转。
自旋锁可以使用在中断处理程序中（此处不能使用信号量，因为它们会导致睡眠），在中断处理程序中使用自旋锁时，一定要在获取锁之前，首先禁止本地中断（在 当前处理器上的中断请求），否则，中断处理程序就会打断正持有锁的内核代码，有可能会试图去争用这个已经持有的自旋锁，这样以来，中断处理程序就会自旋， 等待该锁重新可用，但是锁的持有者在这个中断处理程序执行完毕前不可能运行，这正是我们在前一章节中提到的双重请求死锁，注意，需要关闭的只是当前处理器上的中断，如果中断发生在不同的处理器上，即使中断处理程序在同一锁上自旋，也不会妨碍锁的持有者（在不同处理器上）最终释放锁。
自旋锁的简单理解：
理解自旋锁最简单的方法是把它作为一个变量看待，该变量把一个临界区或者标记为“我当前正在运行，请稍等一会”或者标记为“我当前不在运行，可以被使用”。如果A执行单元首先进入例程，它将持有自旋锁，当B执行单元试图进入同一个例程时，将获知自旋锁已被持有，需等到A执行单元释放后才能进入。
自旋锁的API函数：
其实介绍的几种信号量和互斥机制，其底层源码都是使用自旋锁,可以理解为自旋锁的再包装。所以从这里就可以理解为什么自旋锁通常可以提供比信号量更高的性能。
自旋锁是一个互斥设备，他只能会两个值：“锁定”和“解锁”。它通常实现为某个整数之中的单个位。
“测试并设置”的操作必须以原子方式完成。
任何时候，只要内核代码拥有自旋锁，在相关CPU上的抢占就会被禁止。
适用于自旋锁的核心规则：
（1）任何拥有自旋锁的代码都必须使原子的，除服务中断外（某些情况下也不能放弃CPU,如中断服务也要获得自旋锁。为了避免这种锁陷阱，需要在拥有自旋锁时禁止中断），不能放弃CPU（如休眠，休眠可发生在许多无法预期的地方）。否则CPU将有可能永远自旋下去（死机）。
（2）拥有自旋锁的时间越短越好。
需 要强调的是，自旋锁别设计用于多处理器的同步机制，对于单处理器（对于单处理器并且不可抢占的内核来说，自旋锁什么也不作），内核在编译时不会引入自旋锁 机制，对于可抢占的内核，它仅仅被用于设置内核的抢占机制是否开启的一个开关，也就是说加锁和解锁实际变成了禁止或开启内核抢占功能。如果内核不支持抢 占，那么自旋锁根本就不会编译到内核中。
内核中使用spinlock_t类型来表示自旋锁，它定义在：
typedef struct {
raw_spinlock_t raw_lock;
#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
unsigned int break_lock;
#endif
} spinlock_t;
对于不支持SMP的内核来说，struct raw_spinlock_t什么也没有，是一个空结构。对于支持多处理器的内核来说，struct raw_spinlock_t定义为
typedef struct {
unsigned int slock;
} raw_spinlock_t;
slock表示了自旋锁的状态，“1”表示自旋锁处于解锁状态（UNLOCK），“0”表示自旋锁处于上锁状态（LOCKED）。
break_lock表示当前是否由进程在等待自旋锁，显然，它只有在支持抢占的SMP内核上才起作用。
自旋锁的实现是一个复杂的过程，说它复杂不是因为需要多少代码或逻辑来实现它，其实它的实现代码很少。自旋锁的实现跟体系结构关系密切，核心代码基本也是由汇编语言写成，与体协结构相关的核心代码都放在相关的目录下，比如。对于我们驱动程序开发人员来说，我们没有必要了解这么spinlock的内部细节，如果你对它感兴趣，请参考阅读Linux内核源代码。对于我们驱动的spinlock接口，我们只需包括头文件。在我们详细的介绍spinlock的API之前，我们先来看看自旋锁的一个基本使用格式：
#include
spinlock_t lock = SPIN_LOCK_UNLOCKED;
spin_lock(&lock);
....
spin_unlock(&lock);
从使用上来说，spinlock的API还很简单的，一般我们会用的的API如下表，其实它们都是定义在中的宏接口，真正的实现在中
#include
SPIN_LOCK_UNLOCKED
DEFINE_SPINLOCK
spin_lock_init( spinlock_t *)
spin_lock(spinlock_t *)
spin_unlock(spinlock_t *)
spin_lock_irq(spinlock_t *)
spin_unlock_irq(spinlock_t *)
spin_lock_irqsace(spinlock_t *，unsigned long flags)
spin_unlock_irqsace(spinlock_t *, unsigned long flags)
spin_trylock(spinlock_t *)
spin_is_locked(spinlock_t *)
• 初始化
spinlock有两种初始化形式，一种是静态初始化，一种是动态初始化。对于静态的spinlock对象，我们用 SPIN_LOCK_UNLOCKED来初始化，它是一个宏。当然，我们也可以把声明spinlock和初始化它放在一起做，这就是 DEFINE_SPINLOCK宏的工作，因此，下面的两行代码是等价的。
DEFINE_SPINLOCK (lock);
spinlock_t lock = SPIN_LOCK_UNLOCKED;
spin_lock_init 函数一般用来初始化动态创建的spinlock_t对象，它的参数是一个指向spinlock_t对象的指针。当然，它也可以初始化一个静态的没有初始化的spinlock_t对象。
spinlock_t *lock
......
spin_lock_init(lock);
• 获取锁
内核提供了三个函数用于获取一个自旋锁。
spin_lock：获取指定的自旋锁。
spin_lock_irq：禁止本地中断并获取自旋锁。
spin_lock_irqsace：保存本地中断状态，禁止本地中断并获取自旋锁，返回本地中断状态。
自旋锁是可以使用在中断处理程序中的，这时需要使用具有关闭本地中断功能的函数，我们推荐使用 spin_lock_irqsave，因为它会保存加锁前的中断标志，这样就会正确恢复解锁时的中断标志。如果spin_lock_irq在加锁时中断是关闭的，那么在解锁时就会错误的开启中断。
另外两个同自旋锁获取相关的函数是：
spin_trylock()：尝试获取自旋锁，如果获取失败则立即返回非0值，否则返回0。
spin_is_locked()：判断指定的自旋锁是否已经被获取了。如果是则返回非0，否则，返回0。
• 释放锁
同获取锁相对应，内核提供了三个相对的函数来释放自旋锁。
spin_unlock：释放指定的自旋锁。
spin_unlock_irq：释放自旋锁并激活本地中断。
spin_unlock_irqsave：释放自旋锁，并恢复保存的本地中断状态。
五、读写自旋锁
如 果临界区保护的数据是可读可写的，那么只要没有写操作，对于读是可以支持并发操作的。对于这种只要求写操作是互斥的需求，如果还是使用自旋锁显然是无法满 足这个要求（对于读操作实在是太浪费了）。为此内核提供了另一种锁－读写自旋锁，读自旋锁也叫共享自旋锁，写自旋锁也叫排他自旋锁。
读写自旋锁是一种比自旋锁粒度更小的锁机制，它保留了“自旋”的概念，但是在写操作方面，只能最多有一个写进程，在读操作方面，同时可以有多个读执行单元，当然，读和写也不能同时进行。
读写自旋锁的使用也普通自旋锁的使用很类似，首先要初始化读写自旋锁对象：
// 静态初始化
rwlock_t rwlock = RW_LOCK_UNLOCKED;
//动态初始化
rwlock_t *rwlock;
...
rw_lock_init(rwlock);
在读操作代码里对共享数据获取读自旋锁：
read_lock(&rwlock);
...
read_unlock(&rwlock);
在写操作代码里为共享数据获取写自旋锁：
write_lock(&rwlock);
...
write_unlock(&rwlock);
需要注意的是，如果有大量的写操作，会使写操作自旋在写自旋锁上而处于写饥饿状态（等待读自旋锁的全部释放），因为读自旋锁会自由的获取读自旋锁。
读写自旋锁的函数类似于普通自旋锁，这里就不一一介绍了，我们把它列在下面的表中。
RW_LOCK_UNLOCKED
rw_lock_init(rwlock_t *)
read_lock(rwlock_t *)
read_unlock(rwlock_t *)
read_lock_irq(rwlock_t *)
read_unlock_irq(rwlock_t *)
read_lock_irqsave(rwlock_t *, unsigned long)
read_unlock_irqsave(rwlock_t *, unsigned long)
write_lock(rwlock_t *)
write_unlock(rwlock_t *)
write_lock_irq(rwlock_t *)
write_unlock_irq(rwlock_t *)
write_lock_irqsave(rwlock_t *, unsigned long)
write_unlock_irqsave(rwlock_t *, unsigned long)
rw_is_locked(rwlock_t *)
六、顺序琐
顺序琐（seqlock）是对读写锁的一种优化，若使用顺序琐，读执行单元绝不会被写执行单元阻塞，也就是说，读执行单元可以在写执行单元对被顺序琐保护的共享资源进行写操作时仍然可以继续读，而不必等待写执行单元完成写操作，写执行单元也不需要等待所有读执行单元完成读操作才去进行写操作。
但是，写执行单元与写执行单元之间仍然是互斥的，即如果有写执行单元在进行写操作，其它写执行单元必须自旋在哪里，直到写执行单元释放了顺序琐。
如果读执行单元在读操作期间，写执行单元已经发生了写操作，那么，读执行单元必须重新读取数据，以便确保得到的数据是完整的，这种锁在读写同时进行的概率比较小时，性能是非常好的，而且它允许读写同时进行，因而更大的提高了并发性，
注意，顺序琐由一个限制，就是它必须被保护的共享资源不含有指针，因为写执行单元可能使得指针失效，但读执行单元如果正要访问该指针，将导致Oops。
七、信号量
Linux中的信号量是一种睡眠锁，如果有一个任务试图获得一个已经被占用的信号量时，信号量会将其推进一个等待队列，然后让其睡眠，这时处理器能重获自由，从而去执行其它代码，当持有信号量的进程将信号量释放后，处于等待队列中的哪个任务被唤醒，并获得该信号量。
信号量，或旗标，就是我们在操作系统里学习的经典的P/V原语操作。
P：如果信号量值大于0，则递减信号量的值，程序继续执行，否则，睡眠等待信号量大于0。
V：递增信号量的值，如果递增的信号量的值大于0，则唤醒等待的进程。
信号量的值确定了同时可以有多少个进程可以同时进入临界区，如果信号量的初始值始1，这信号量就是互斥信号量（MUTEX）。对于大于1的非0值信号量，也可称为计数信号量（counting semaphore）。对于一般的驱动程序使用的信号量都是互斥信号量。
类似于自旋锁，信号量的实现也与体系结构密切相关，具体的实现定义在头文件中，对于x86_32系统来说，它的定义如下：
struct semaphore {
atomic_t count;
int sleepers;
wait_queue_head_t wait;
};
信号量的初始值count是atomic_t类型的，这是一个原子操作类型，它也是一个内核同步技术，可见信号量是基于原子操作的。我们会在后面原子操作部分对原子操作做详细介绍。
信号量的使用类似于自旋锁，包括创建、获取和释放。我们还是来先展示信号量的基本使用形式：
static DECLARE_MUTEX(my_sem);
......
if (down_interruptible(&my_sem))
{
return -ERESTARTSYS;
}
......
up(&my_sem)
Linux内核中的信号量函数接口如下：
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
seam_init(struct semaphore *, int);
init_MUTEX(struct semaphore *);
init_MUTEX_LOCKED(struct semaphore *)
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
• 初始化信号量
信号量的初始化包括静态初始化和动态初始化。静态初始化用于静态的声明并初始化信号量。
static DECLARE_SEMAPHORE_GENERIC(name, count);
static DECLARE_MUTEX(name);
对于动态声明或创建的信号量，可以使用如下函数进行初始化：
seam_init(sem, count);
init_MUTEX(sem);
init_MUTEX_LOCKED(struct semaphore *)
显然，带有MUTEX的函数始初始化互斥信号量。LOCKED则初始化信号量为锁状态。
• 使用信号量
信号量初始化完成后我们就可以使用它了
down_interruptible(struct semaphore *);
down(struct semaphore *)
down_trylock(struct semaphore *)
up(struct semaphore *)
down函数会尝试获取指定的信号量，如果信号量已经被使用了，则进程进入不可中断的睡眠状态。down_interruptible则会使进程进入可中断的睡眠状态。关于进程状态的详细细节，我们在内核的进程管理里在做详细介绍。
down_trylock尝试获取信号量， 如果获取成功则返回0，失败则会立即返回非0。
当退出临界区时使用up函数释放信号量，如果信号量上的睡眠队列不为空，则唤醒其中一个等待进程。
八、读写信号量
类似于自旋锁，信号量也有读写信号量。读写信号量API定义在头文件中，它的定义其实也是体系结构相关的，因此具体实现定义在头文件中，以下是x86的例子：
struct rw_semaphore {
signed long count;
spinlock_t wait_lock;
struct list_head wait_list;
};
Ⅵ Linux内核头文件
#include <linux/mole.h>:模块
#include <linux/kernel.h>:内核
#include <linux/sched.h>:调度器
#include <linux/signal.h>：信号量
#include <linux/errno.h>:里面定义一些“错误”信息
#include <linux/fcntl.h>:file control
#include <linux/spinlock.h>:环行锁,实现临界区的互斥访问
其他的我不是很清楚，你可以去google一下.
Ⅶ linux自旋锁使用时需要注意的几个地方
1、在内核多线程编程时，为了保护共享资源通常需要使用锁，而使用的比较多的就是spinlock，但需要注意的是：所有临界区代码都需要加锁保护，否则就达不到保护效果。也就是，访问共享资源的多个线程需要协同工作共同加锁才能保证不出错。在实际写代码时，有时候会网掉这一点，以致出现各种稀奇古怪的问题，而且很难找到原因。
2、在出现两个和多个自旋锁的嵌套使用时，务必注意加锁和解锁的顺序。
比如：在线程1中，spinlock A -> spinlock B -> spin unlock B -> spin unlock A ；那么，在需要同步的线程2中，若需要加相同的锁，则顺序也应该保持相同，spinlock A -> spinlock B -> spin unlock B -> spin unlock A ；否则，很有可能出现死锁。
3、spinlock保护的代码执行时间要尽量短，若有for循环之类的代码，则一定要确保循环可以在短时间可以退出，从而使得spinlock可以释放。
4、spinlock所保护的代码在执行过程中不能睡眠。比如，在spinlock和spinunlock之间不能调用kmalloc, _from_user,kthread_stop等调用，因为这些函数调用均有可能导致线程睡眠。
5、spinlock在实际使用时有如下几种类型，spin_lock，spin_lock_bh，spin_lock_irqsave。在具体使用时，需要根据被保护临界区锁处的上下文选择合适的spinlock类型。
spin_lock用于不同cpu线程间同步，spin_lock_bh和spin_lock_irqsave主要用于本cpu线程间的同步，前者关软中断，后者关硬中断。
Ⅷ 如何调用spin_lock函数
linux/spinlock.h是系统编程（包括驱动程序的编写）中用到的头文件。应用程序只能通过系统调用来使用内核提供的功能。
Ⅸ Linux下各种锁的理解和使用及总结解决epoll惊群问题(面试常考)-
锁出现的原因
临界资源是什么: 多线程执行流所共享的资源
锁的作用是什么, 可以做原子操作, 在多线程中针对临界资源的互斥访问... 保证一个时刻只有一个线程可以持有锁对于临界资源做修改操作...
任何一个线程如果需要修改，向临界资源做写入操作都必须持有锁，没有持有锁就不能对于临界资源做写入操作.
锁 ： 保证同一时刻只能有一个线程对于临界资源做写入操作 (锁地功能)
再一个直观地代码引出问题，再从指令集的角度去看问题
上述一个及其奇怪的结果，这个结果每一次运行都可能是不一样的，Why ？ 按照我们本来的想法是每一个线程 + 20000000 结果肯定应该是60000000呀，可以就是达不到这个值
为何？ (深入汇编指令来看) 一定将过程放置到汇编指令上去看就可以理解这个过程了.
a++; 或者 a += 1; 这些操作的汇编操作是几个步骤?
其实是三个步骤：
正常情况下，数据少，操作的线程少，问题倒是不大，想一想要是这样的情况下，操作次数大，对齐操作的线程多，有些线程从中间切入进来了，在运算之后还没写回内存就另外一个线程切入进来同时对于之前的数据进行++ 再写回内存, 啥效果，多次++ 操作之后结果确实一次加加操作后的结果。 这样的操作 (术语叫做函数的重入) 我觉得其实就是重入到了汇编指令中间了，还没将上一次运算的结果写回内存就重新对这个内存读取再运算写入，结果肯定和正常的逻辑后的结果不一样呀
来一幅图片解释一下
咋办? 其实问题很清楚，我们只需要处理的是多条汇编指令不能让它中间被插入其他的线程运算. （要想自己在执行汇编指令的时候别人不插入进来） 将多条汇编指令绑定成为一条指令不就OK了嘛。
也就是原子操作！！！
不会原子操作？操作系统给咱提供了线程的 绑定方式工具呀：mutex 互斥锁(互斥量)， 自旋锁(spinlock)， 读写锁（readers-writer lock） 他们也称作悲观锁. 作用都是一个样，将多个汇编指令锁成为一条原子操作 (此处的汇编指令也相当于如下的临界资源)
悲观锁：锁如其名，每次都悲观地认为其他线程也会来修改数据，进行写入操作，所以会在取数据前先加锁保护，当其他线程想要访问数据时，被阻塞挂起
乐观锁：每次取数据的时候，总是乐观地认为数据不会被其他线程修改，因此不上锁。但是在更新数据前， 会判断其他数据在更新前有没有对数据进行修改。
互斥锁
最为常见使用地锁就是互斥锁, 也称互斥量. mutex
特征，当其他线程持有互斥锁对临界资源做写入操作地时候，当前线程只能挂起等待，让出CPU，存在线程间切换工作
解释一下存在线程间切换工作 : 当线程试图去获取锁对临界资源做写入操作时候，如果锁被别的线程正在持有，该线程会保存上下文直接挂起，让出CPU，等到锁被释放出来再进行线程间切换，从新持有CPU执行写入操作
互斥锁需要进行线程间切换，相比自旋锁而言性能会差上许多，因为自旋锁不会让出CPU, 也就不需要进行线程间切换的步骤，具体原理下一点详述
加互斥量(互斥锁)确实可以达到要求，但是会发现运行时间非常的长，因为线程间不断地切换也需要时间, 线程间切换的代价比较大.
相关视频推荐
你绕不开的组件—锁，4个方面手撕锁的多种实现
“惊群”原理、锁的设计方案及绕不开的“死锁”问题
学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括 C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享
自旋锁
spinlock.自旋锁.
对比互斥量(互斥锁)而言，获取自旋锁不需要进行线程间切换，如果自旋锁正在被别的线程占用，该线程也不会放弃CPU进行挂起休眠，而是恰如其名的在哪里不断地循环地查看自旋锁保持者(持有者)是否将自旋锁资源释放出来... （自旋地原来就是如此）
口语解释自旋：持有自旋锁的线程不释放自旋锁，那也没有关系呀，我就在这里不断地一遍又一遍地查询自旋锁是否释放出来，一旦释放出来我立马就可以直接使用 (因为我并没有挂起等待，不需要像互斥锁还需要进行线程间切换，重新获取CPU，保存恢复上下文等等操作)
哪正是因为上述这些特点，线程尝试获取自旋锁，获取不到不会采取休眠挂起地方式，而是原地自旋（一遍又一遍查询自旋锁是否可以获取）效率是远高于互斥锁了. 那我们是不是所有情况都使用自旋锁就行了呢，互斥锁就可以放弃使用了吗????
解释自旋锁地弊端：如果每一个线程都仅仅只是需要短时间获取这个锁，那我自旋占据CPU等待是没啥问题地。要是线程需要长时间地使用占据（锁）。。。 会造成过多地无端占据CPU资源，俗称站着茅坑不拉屎... 但是要是仅仅是短时间地自旋，平衡CPU利用率 + 程序运行效率 （自旋锁确实是在有些时候更加合适）
自旋锁需要场景：内核可抢占或者SMP(多处理器)情况下才真正需求 (避免死锁陷入死循环，疯狂地自旋，比如递归获取自旋锁. 你获取了还要获取，但是又没法释放)
自旋锁的使用函数其实和互斥锁几乎是一摸一样地，仅仅只是需要将所有的mutex换成spin即可
仅仅只是在init存在些许不同
何为惊群，池塘一堆, 我瞄准一条插过去，但是好似所有的都像是觉着自己正在被插一样的四处逃窜。 这个就是惊群的生活一点的理解
惊群现象其实一点也不少，比如说 accept pthread_cond_broadcast 还有多个线程共享epoll监视一个listenfd 然后此刻 listenfd 说来 SYN了，放在了SYN队列中，然后完成了三次握手放在了 accept队列中了, 现在问题是这个connect我应该交付给哪一个线程处理呢.
多个epoll监视准备工作的线程 就是这群 ()，然后connet就是鱼叉，这一叉下去肯定是所有的 epoll线程都会被惊醒 (多线程共享listenfd引发的epoll惊群)
同样如果将上述的多个线程换成多个进程共享监视 同一个 listenfd 就是(多进程的epoll惊群现象)
咱再画一个草图再来理解一下这个惊群:
如果是多进程道理是一样滴，仅仅只是将所有的线程换成进程就OK了
终是来到了今天的正题了: epoll惊群问题地解决上面了...
首先 先说说accept的惊群问题，没想到吧accept 平时大家写它的多线程地时候，多个线程同时accept同一个listensock地时候也是会存在惊群问题地，但是accept地惊群问题已经被Linux内核处理了: 当有新的连接进入到accept队列的时候，内核唤醒且仅唤醒一个进程来处理
但是对于epoll的惊群问题，内核却没有直接进行处理。哪既然内核没有直接帮我们处理，我们应该如何针对这种现象做出一定的措施呢?
惊群效应带来的弊端: 惊群现象会造成epoll的伪唤醒，本来epoll是阻塞挂起等待着地，这个时候因为挂起等待是不会占用CPU地。。。 但是一旦唤醒就会占用CPU去处理发生地IO事件， 但是其实是一个伪唤醒，这个就是对于线程或者进程的无效调度。然而进程或者线程地调取是需要花费代价地，需要上下文切换。需要进行进程(线程)间的不断切换... 本来多核CPU是用来支持高并发地，但是现在却被用来无效地唤醒，对于多核CPU简直就是一种浪费 （浪费系统资源） 还会影响系统的性能.
解决方式（一般是两种）
Nginx的解决方式:
加锁：惊群问题发生的前提是多个进程（线程）监听同一个套接字(listensock)上的事件，所以我们只让一个进程（线程）去处理监听套接字就可以了。
画两张图来理解一下：
上述还没有进行一个每一个进程都对应一个listensock 而是多线程共享一个listensock 运行结果如下
所有的线程同时被唤醒了，但是实际上会处理连接的仅仅只是一个线程，
咱仅仅只是将主线程做如上这样一个简单的修改，每一个线程对应一个listensock；每一个线程一个独有的监视窗口，将问题抛给内核去处理，让内核去负载均衡 ： 结果如下
仅仅唤醒一个线程来进行处理连接，解决了惊群问题
本文通过介绍两种锁入手，以及为什么需要锁，锁本质就是为了保护，持有锁你就有权力有能力操作写入一定的临界保护资源，没有锁你就不行需要等待，本质其实是将多条汇编指令绑定成原子操作
然后介绍了惊群现象，通过一个巧妙地例子，扔一颗石子，只是瞄准一条鱼扔过去了，但是整池鱼都被惊醒了，
对应我们地实际问题就是， 多个线程或者进程共同监视同一个listensock。。。。然后IO连接事件到来地时候本来仅仅只是需要一个线程醒过来处理即可，但是却会使得所有地线程（进程）全部醒过来，造成不必要地进程线程间切换，多核CPU被浪费喔，系统资源被浪费
处理方式 一。 Nginx 源码加互斥锁处理。。 二。设置SO_REUSEPORT, 使得多个进程线程可以同时连接同一个port , 为每一个进程线程搞一个listensock... 将问题抛给内核去处理，让他去负载均衡地仅仅将IO连接事件分配给一个进程或线程