前言：本文算是本人对linux有关资源共享的理解，与读者共享之，不足之处还请多多指出
不废话，先献上先遣图说话-交代一下背景，有道是：天王盖盖地虎，宝塔镇河妖... ...
?
LDD3中关于 Concurrency and Race Conditions的背景交代的很清楚，大概就是说当前多内核，多线程，且单内核支持抢占和中断的现代环境下，程序运行过程中不可避免的会发生资源的并发访问并从而产生竞赛，如果内核作为整个系统的“大管家”不加以治理和疏通，情况将是灾难性的，继续贴图来说明这种“race”有多激烈：
可以看见，有关资源的争夺对比九子夺嫡那是有过之而无不及，这其中包括但不限于core内进程之间，进程与中断之间，不同core之间...在这样一种残酷的竞争下，内核的措施和方案也有条不紊的推出，虽然这些关于并发控制的方案形态各异，适用于不同的场景，但其核心思想从未改变过，这里引用一下经典：making sure that only one thread of execution can manipulate a shared resource at any time.
?有了核心思想，当然得有一套通用的法则来建立约束，这就是critical sections，国内翻译成临界区。无论是信号量(Semaphores)，互斥量(Mutexes)，还是自旋锁（spin_lock）都是基于critical sections来实现并发控制，下面由我来进行一一介绍，再加上一个完成量（completion）吧
先来说一下信号量（Semaphores）：
简单来说：信号量（Semaphores）是通过进行PV操作实现对整数值的管理从而实现对信号量的hold和release，当前进程在对信号量hold过程中，一般来说（sema_init时val设置为1）其他进程也想“把握”此信号量，那只有乖乖的等着，处于等待状态（也可以叫睡眠状态），等到当前进程在临界区域实现了某些操作后release信号量，这些处于等待状态的进程会被唤起“起床干活”，有可能再次参与到这场关于信号量的擂台赛中。linux当中也提供了Semaphores的初始化，PV操作的API接口，我们只需要调用就是了嘛，现阶段的拿来主义并不丢人，当然这也是linux内核的本意啦
这里稍微啰嗦一下：信号量的hold只能存在于不同core的进程与进程之间，进程与中断之间是绝对不能用信号量来并发控制的，会导致死锁的情况发生（同core的进程与进程之间的抢占也会出现），师爷不说过了嘛，你们哪怕花点spin_lock呢？
?另外信号量（Semaphores）的延伸拓展Reader/Writer Semaphores-读写信号量也有必要简单阐述一下：读写信号量的引入有提高performance的成分在里面，因为Semaphores这个老实人同一时间只允许一个进程拥有它，读写信号量引入后可以有多个进程同时在同一时间读，但同一时间写是绝对不允许的，并且读操作要给写操作让位的-换言之只有等写完了，众多的进程才能开始读操作
?
?再来说一下自旋锁（spin_lock）：
?就我个人而言，自旋锁（spin_lock）的机制还是比较有意思的，跟CPU的架构体系有关系，涉及到的原子操作和中断屏蔽就不在这里一一展开了，理解自旋锁最简单的方法是把它当做一个变量来看待，该变量把一个临界区域标记为“我当前正在运行，请稍等一会儿”，或者标记为“我不在运行。可以被使用”。如果A执行单元（不管是进程还是中断）首先hold了该自旋锁，当B执行单元也试图hold该自旋锁，需要等待A释放后才能进入
同样啰嗦一下：应用自旋锁（spin_lock）进入临界区域后是禁止了同core的抢占行为的，其他core的抢占行为是不影响当前执行单元进入临界区域后所做的操作的，剩下的就是同core的中断行为对当前执行单元的影响了，此时linux默默的拿出了spin_lock_irqsave和spin_lock_irq
?自旋锁的使用注意事项：
?
?
?
?
