linux的临界区
① 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进入临界去开关中断的几种方式
进入中断时候关闭全局的中断是为了避免程序处理中断过程中，再进入另一个中断打乱执行的顺序，也就是为了防止中断嵌套的情况发生。比如在irq_handler函数中首先就应该关闭中断。或者，在某些操作顺序中是不允许中断发生打断的情况。例如在驱动中常用的方式：
unsigned int flag;
local_irq_save(&flag);
spin_loc_irqsave 禁止中断(只在本地处理器)在获得自旋锁之前; 之前的中断状态保存在 flags 里. 如果你绝对确定在你的处理器上没有禁止中断的(或者, 换句话说, 你确信你应当在你释放你的液陆尘闹禅自旋锁时打开中断)，你可以使用 spin_lock_irq 代替, 并且不必保持跟踪 flags. 最后, spin_lock_bh 在获取锁之前禁止软件中断, 但是硬件中断留作打开的。感觉现在自己对互斥和中断的悉铅关系给搞糊涂了，例如出现这样的情况，在进入临界区后，发生了一个中断在进入中断处理函数中，也需要临界区的资源，但是它获得不了，是不是这个中断处理函数被挂起到等待队列中呢？还是产生了死锁呢？
③ Linux内核中的RCU机制
Linux内核中的RCU机制
RCU的设计思想比较明确，通过新老指针替换的方式来实现免锁方式的共享保护。但是具体到代码的层面，理解起来多扒岩少还是会有些困难。下面我准备了关于Linux内核中的RCU机制的文章，提供给大家参考!
RCU读取侧进入临界区的标志是调用rcu_read_lock，这个函数的代码是：
static inline void rcu_read_lock(void)
{
__rcu_read_lock();
__acquire(RCU);
rcu_read_acquire();
}
该实现里面貌似有三个函数调用，但实质性的工作由第一个函数__rcu_read_lock()来完成，__rcu_read_lock()通过调用 preempt_disable()关闭内核可抢占性。但是中断是允许的，假设读取者正处于rcu临界区中且刚读取了一个共享数据区的指针p(但是还没有访问p中的数据成员)，发生了一个中断，而该中断处理例程ISR恰好需要修改p所指向的数据区，按照RCU的设计原则，ISR会新分配一个同样大小的数据区new_p，再把老数据区p中的数据拷贝到新数据区，接着是在new_p的基础上做数据修改的工作(因为是在new_p空间中修改，所以不存在对p的并发访问，因此说RCU是一种免锁机制，原因就在这里)，ISR在把数据更新的工作完成后，将new_p赋值给p(p=new_p),最后它会再注册一个回调函数用以在适当的时候释放老指针p。因此，只要对老指针p上的所有引用都结束了，释放p就不会有问题。当中断处理例程做完这些工作返回后，被中断的进程将依然访问到p空间上的数据，芦滑也就是老数据，这样的结果是RCU机制所允许的。RCU规则对读取者与写入者之间因指针切换所造成的短暂的资源视图不一致问题是允许的。
接下来关于RCU一个有趣的问题是：何时才能释放老指针。我见过很多书中对此的'回答是：当系统中所有处理器上都发生了一次进程切换。这种程式化的回答常常让刚接触RCU机制的读者感到一头雾水，为什么非要等所有处理器上都发生一次进程切换才可以调用回调函数释放老指针呢?这其实是RCU的设计规则决定的： 所有对老指针的引用只可能发生在rcu_read_lock与rcu_read_unlock所包括的临界区中，而在这个临界区中不可能发生进程切换，而一旦出了该临界区就不应该再有任何形式的对老指针p的引用。很明显，这个规则要求读取者在临界区中不能发生进程切换，因为一旦有进程切换，释放老指针的回调函数就有可能被调用，从而导致老指针被释放掉，当被切换掉的进程被重新调度运行时它就有可能引用到一个被释放掉的内存空间。
现在我们看到为什么rcu_read_lock只需要关闭内核可抢占性就可以了，因为它使得即便在临界区中发生了中断，当前进程也不可能被切换除去。 内核开发者，确切地说，RCU的设计者所能做的只能到这个程度。接下来就是使用者的责任了，如果在rcu的临界区中调用了一个函数，该函数可能睡眠，那么RCU的设计规则就遭到了破坏，系统将进入一种不稳定的状态。
这再次说明，如果想使用一个东西，一定要搞清楚其内在的机制，象上面刚提到的那个例子，即便现在程序不出现问题，但是系统中留下的隐患如同一个定时炸弹， 随时可能被引爆，尤其是过了很长时间问题才突然爆发出来。绝大多数情形下，找到问题所花费的时间可能要远远大于静下心来仔细搞懂RCU的原理要多得多。
RCU中的读取者相对rwlock的读取者而言，自由度更高。因为RCU的读取者在访问一个共享资源时，不需要考虑写入者的陪此腊感受，这不同于rwlock的写入者，rwlock reader在读取共享资源时需要确保没有写入者在操作该资源。两者之间的差异化源自RCU对共享资源在读取者与写入者之间进行了分离，而rwlock的 读取者和写入者则至始至终只使用共享资源的一份拷贝。这也意味着RCU中的写入者要承担更多的责任，而且对同一共享资源进行更新的多个写入者之间必须引入某种互斥机制，所以RCU属于一种"免锁机制"的说法仅限于读取者与写入者之间。所以我们看到：RCU机制应该用在有大量的读取操作，而更新操作相对较少的情形下。此时RCU可以大大提升系统系能，因为RCU的读取操作相对其他一些有锁机制而言，在锁上的开销几乎没有。
实际使用中，共享的资源常常以链表的形式存在，内核为RCU模式下的链表操作实现了几个接口函数，读取者和使用者应该使用这些内核函数，比如 list_add_tail_rcu, list_add_rcu，hlist_replace_rcu等等，具体的使用可以参考某些内核编程或者设备驱动程序方面的资料。
在释放老指针方面，Linux内核提供两种方法供使用者使用，一个是调用call_rcu,另一个是调用synchronize_rcu。前者是一种异步 方式，call_rcu会将释放老指针的回调函数放入一个结点中，然后将该结点加入到当前正在运行call_rcu的处理器的本地链表中，在时钟中断的 softirq部分(RCU_SOFTIRQ)， rcu软中断处理函数rcu_process_callbacks会检查当前处理器是否经历了一个休眠期(quiescent，此处涉及内核进程调度等方面的内容)，rcu的内核代码实现在确定系统中所有的处理器都经历过了一个休眠期之后(意味着所有处理器上都发生了一次进程切换，因此老指针此时可以被安全释放掉了)，将调用call_rcu提供的回调函数。
synchronize_rcu的实现则利用了等待队列，在它的实现过程中也会向call_rcu那样向当前处理器的本地链表中加入一个结点，与 call_rcu不同之处在于该结点中的回调函数是wakeme_after_rcu，然后synchronize_rcu将在一个等待队列中睡眠，直到系统中所有处理器都发生了一次进程切换，因而wakeme_after_rcu被rcu_process_callbacks所调用以唤醒睡眠的 synchronize_rcu，被唤醒之后，synchronize_rcu知道它现在可以释放老指针了。
所以我们看到，call_rcu返回后其注册的回调函数可能还没被调用，因而也就意味着老指针还未被释放，而synchronize_rcu返回后老指针肯定被释放了。所以，是调用call_rcu还是synchronize_rcu，要视特定需求与当前上下文而定，比如中断处理的上下文肯定不能使用 synchronize_rcu函数了。 ;
④ 什么是临界区
临界区指的是一个访问共用资源（例如：共用设备或是共用存储器）的程序片段，而这些共用资源又无法同时被多个线程访问的特性。
当有线程进入临界区段时，其他线程或是进程必须等待（例如：bounded waiting 等待法），有一些同步的机制必须在临界区段的进入绝带缺点与离开点实现，以确保这些共用资源是被互斥获得使用，例如：semaphore。只能被单一线程访问的设备，例如：打印机。
进程进入临界区的调度原则是：
1、如果有若干进程要求进入空闲的临界区，一次仅允许一个进程进入。
2、任何时候，处于临界区内的进程不可多于一个。如已有进程进入自己的临界区，则其它所有试图进入临界区的进程必须等待。
3、进入临界行渣区的进程要在有限时间内退出，以便其它进程能及时进入自己的并辩临界区。
4、如果进程不能进入自己的临界区，则应让出CPU，避免进程出现“忙等”现象。
⑤ 一文搞懂 ， Linux内核—— 同步管理（下）
上面讲的自旋锁，信号量和互斥锁的实现，都是使用了原子操作指令。由于原子操作会 lock，当线程在多个 CPU 上争抢进入临界区的时候，都会操作那个在多个 CPU 之间共享的数据 lock。CPU 0 操作了 lock，为了数据的一致性，CPU 0 的操作会导致其他 CPU 的 L1 中的 lock 变成 invalid，在随后的来自其他 CPU 对 lock 的访问会导致 L1 cache miss（更准确的说是communication cache miss），必须从下一个 level 的 cache 中获取。
这就会使缓存一致性变得很糟，导致性能下降。所以内核提供一种新的同步方式：RCU（读-复制-更新）。
RCU 解决了什么
RCU 是读写锁的高性能版本，它的核心理念是读者访问的同时，写者可以更新访问对象的副本，但写者需要等待所有读者完成访问之后，才能删除老对象。读者没有任何同步开销，而写者的同步开销则取决于使用的写者间同步机制。
RCU 适用于需要频繁的读取数据，而相应修改数据并不多的情景，例如在文件系统中，经常需要查找定位目录，而对目录的修改相对来说并不多，这就是 RCU 发挥作用的最佳场景。
RCU 例子
RCU 常用的接口如下图所示：
为了更好的理解，在剖析 RCU 之前先看一个例子：
#include<linux/kernel.h>#include<linux/mole.h>#include<linux/init.h>#include<linux/slab.h>#include<linux/spinlock.h>#include<linux/rcupdate.h>#include<linux/kthread.h>#include<linux/delay.h>structfoo{inta;structrcu_headrcu;};staticstructfoo*g_ptr;staticintmyrcu_reader_thread1(void*data)//读者线程1{structfoo*p1=NULL;while(1){if(kthread_should_stop())break;msleep(20);rcu_read_lock();mdelay(200);p1=rcu_dereference(g_ptr);if(p1)printk("%s: read a=%d\n",__func__,p1->a);rcu_read_unlock();}return0;}staticintmyrcu_reader_thread2(void*data)//读者线程2{structfoo*p2=NULL;while(1){if(kthread_should_stop())break;msleep(30);rcu_read_lock();mdelay(100);p2=rcu_dereference(g_ptr);if(p2)printk("%s: read a=%d\n",__func__,p2->a);rcu_read_unlock();}return0;}staticvoidmyrcu_del(structrcu_head*rh)//回收处理操作{structfoo*p=container_of(rh,structfoo,rcu);printk("%s: a=%d\n",__func__,p->a);kfree(p);}staticintmyrcu_writer_thread(void*p)//写者线程{structfoo*old;structfoo*new_ptr;intvalue=(unsignedlong)p;while(1){if(kthread_should_stop())break;msleep(250);new_ptr=kmalloc(sizeof(structfoo),GFP_KERNEL);old=g_ptr;*new_ptr=*old;new_ptr->a=value;rcu_assign_pointer(g_ptr,new_ptr);call_rcu(&old->rcu,myrcu_del);printk("%s: write to new %d\n",__func__,value);value++;}return0;}staticstructtask_struct*reader_thread1;staticstructtask_struct*reader_thread2;staticstructtask_struct*writer_thread;staticint__initmy_test_init(void){intvalue=5;printk("figo: my mole init\n");g_ptr=kzalloc(sizeof(structfoo),GFP_KERNEL);reader_thread1=kthread_run(myrcu_reader_thread1,NULL,"rcu_reader1");reader_thread2=kthread_run(myrcu_reader_thread2,NULL,"rcu_reader2");writer_thread=kthread_run(myrcu_writer_thread,(void*)(unsignedlong)value,"rcu_writer");return0;}staticvoid__exitmy_test_exit(void){printk("goodbye\n");kthread_stop(reader_thread1);kthread_stop(reader_thread2);kthread_stop(writer_thread);if(g_ptr)kfree(g_ptr);}MODULE_LICENSE("GPL");mole_init(my_test_init);mole_exit(my_test_exit);
执行结果是：
myrcu_reader_thread2:reada=0myrcu_reader_thread1:reada=0myrcu_reader_thread2:reada=0myrcu_writer_thread:writetonew5myrcu_reader_thread2:reada=5myrcu_reader_thread1:reada=5myrcu_del:a=0
RCU 原理
可以用下面一张图来总结，当写线程 myrcu_writer_thread 写完后，会更新到另外两个读线程 myrcu_reader_thread1 和 myrcu_reader_thread2。读线程像是订阅者，一旦写线程对临界区有更新，写线程就像发布者一样通知到订阅者那里，如下图所示。
写者在拷贝副本修改后进行 update 时，首先把旧的临界资源数据移除（Removal）；然后把旧的数据进行回收（Reclamation）。结合 API 实现就是，首先使用 rcu_assign_pointer 来移除旧的指针指向，指向更新后的临界资源；然后使用 synchronize_rcu 或 call_rcu 来启动 Reclaimer，对旧的临界资源进行回收（其中 synchronize_rcu 表示同步等待回收，call_rcu 表示异步回收）。
为了确保没有读者正在访问要回收的临界资源，Reclaimer 需要等待所有的读者退出临界区，这个等待的时间叫做宽限期（Grace Period）。
Grace Period
中间的黄色部分代表的就是 Grace Period，中文叫做宽限期，从 Removal 到 Reclamation，中间就隔了一个宽限期，只有当宽限期结束后，才会触发回收的工作。宽限期的结束代表着 Reader 都已经退出了临界区，因此回收工作也就是安全的操作了。
宽限期是否结束，与 CPU 的执行状态检测有关，也就是检测静止状态 Quiescent Status。
Quiescent Status
Quiescent Status，用于描述 CPU 的执行状态。当某个 CPU 正在访问 RCU 保护的临界区时，认为是活动的状态，而当它离开了临界区后，则认为它是静止的状态。当所有的 CPU 都至少经历过一次 Quiescent Status 后，宽限期将结束并触发回收工作。
因为 rcu_read_lock 和 rcu_read_unlock 分别是关闭抢占和打开抢占，如下所示：
staticinlinevoid__rcu_read_lock(void){preempt_disable();}
staticinlinevoid__rcu_read_unlock(void){preempt_enable();}
所以发生抢占，就说明不在 rcu_read_lock 和 rcu_read_unlock 之间，即已经完成访问或者还未开始访问。
Linux 同步方式的总结
资料免费领
学习直通车
⑥ linux下,怎样进人临界区
先贴示范代档键码：销闭
//--------------------tmutex.h开始------------------------------
//实现linux的互斥量c++封装亏蠢裂
#ifndef TMUTEX_H
#define TMUTEX_H
#include <pthread.h>
//线程互斥量
struct ThreadMutex
{
ThreadMutex()
{
pthread_mutex_init(&mtx,NULL);
}
~ThreadMutex()
{
pthread_mutex_destroy( &mtx );
}
inline void lock()
{
pthread_mutex_lock( &mtx );
}
inline void unlock()
{
pthread_mutex_unlock( &mtx );
}
pthread_mutex_t mtx;
};
//空互斥量，即调用lock时什么事都不做。
struct NullMutex
{
inline void lock()
{
}
inline void unlock()
{
}
};
template<class T>
class CAutoGuard
{
public:
CAutoGuard(T &mtx) : m_mtx(mtx)
{
m_mtx.lock();
}
~CAutoGuard()
{
m_mtx.unlock();
}
protected:
T &m_mtx;
};
#define AUTO_GUARD( guard_tmp_var, MUTEX_TYPE, mtx ) \
CAutoGuard<MUTEX_TYPE> guard_tmp_var(mtx)
#endif
//-------------------------tmutex.h结束------------------------------------------
//-------------------------主程序文件test.cpp开始----------------------------------
#include <pthread.h>
#include "tmutex.h"
#include <iostream>
using namespace std;
typedef ThreadMutex MUTEX_TYPE; //使用线程互斥量的互斥量类型
//typedef NullMutex MUTEX_TYPE; //不使用互斥量的互斥量类型
MUTEX_TYPE g_mtx; //互斥量变量定义
void *print_msg_thread(void *parg);
void *print_msg_thread(void *parg)
{//工作线程，用循环模拟一个的工作。
char *msg = (char *)parg;
AUTO_GUARD( gd, MUTEX_TYPE, g_mtx );
for(int i=0; i<10; i++ )
{
cout << msg << endl;
sleep( 1 );
}
return NULL;
}
int main()
{
pthread_t t1,t2;
//创建两个工作线程，第1个线程打印10个1，第2个线程打印10个2。
pthread_create( &t1, NULL, &print_msg_thread, (void *)"1" );
pthread_create( &t2, NULL, &print_msg_thread, (void *)"2" );
//等待线程结束
pthread_join( t1,NULL);
pthread_join( t2,NULL);
return 0;
}
//-----------------------------主程序文件test.cpp结束
看了上面的示例代码及注释，相信已经了解该代码的功能。我们在主程序中创建两个线程，第1个线程循环打印10个1，第2个线程循环打印10个2。由于线程的特性，两个线程并不一定会按顺序执行，它们可能会被轮流调度执行。
如果两个线程被轮流调度执行，那么所打印的10个1和10个2的排列顺序则不固定。线程1打印了几个字符后，可能会别打断，CPU被分配到线程2上去执行。这样可以尽可能让每个线程都得到CPU资源。但是另一方面也带来了问题。如果两个线程共同访问了一个变量。并且两个线程都会修改它，在修改未完成被打断的话，会使得最后修改的结果和预期的不一致。对于不能被打断的操作我们叫它原子操作。为了能使线程中的某段代码成为原子操作，我们就得使用互斥量。如本例所示的打印10个字符，如果我们不使用互斥量那么这个打印顺序就会被破坏，使用了互斥量后，线程1未离开互斥量所管的区域，线程2是不能再次进入的。这就保证了打印过程的原子操作性。
Linux中使用临界区加锁的方法是用pthread_mutex_t进行操作，分别调用pthread_mutex_init、pthread_mutex_destroy创建和释放pthread_mutex变量，调用pthread_mutex_lock和pthread_mutex_unlock进行加锁和解锁。其中pthread_mutex_init和pthread_mutex_destroy只要在最开始的时候和不用的时候各调用一次，pthread_mutex_lock和pthread_mutex_unlock则是在每次加锁和解锁时调用。要注意的是它们的调用必须一一对应。
本例的互斥量使用了C++的构造和析构以及模板的特性进行封装，保证分配和释放、加锁和解锁的成对，使得互斥量的使用更加简单。加锁时只需一个语句：AUTO_GUARD( gd, MUTEX_TYPE, g_mtx ); 该语句是个宏，展开宏得到的代码是：CAutoGuard<MUTEX_TYPE> gd(g_mtx); CAutoGuard对象的构造和析构自动调用g_mtx的lock和unlock函数进行加锁解锁。而锁的类型就看MUTEX_TYPE的定义了。下面这两行是互斥量锁类型的定义：
typedef ThreadMutex MUTEX_TYPE; //使用线程互斥量的互斥量类型
//typedef NullMutex MUTEX_TYPE; //不使用互斥量的互斥量类型
其中第1行的类型是ThreadMutex，我们看该struct的定义，在lock和unlock函数中分别调用了pthread_mutex_lock和pthread_mutex_unlock，这样就实现了资源的锁定和解锁。
而第2行的类型是NullMutex，在该struct的定义中，lock和unlock函数都是空函数，没有执行任何锁定解锁操作。
因此，将MUTEX_TYPE的类型改为ThreadMutex或NullMutex就可以实现使用或不使用互斥量的效果。
将上述两个文件保存并编译：g++ tmutex.h test.cpp -lpthread -o test
编译完输出test可执行文件。输入./test执行程序。下面是使用互斥量和不使用互斥量的执行结果：
使用互斥量：
[root@hjclinux sampthread]# g++ tmutex.h test.cpp -lpthread -o test
[root@hjclinux sampthread]# ./test
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
将test.cpp中的MUTEX_TYPE定义改成typedef NullMutex MUTEX_TYPE再编译执行结果如下：
[root@hjclinux sampthread]# ./test
1
2
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
2
1
由于线程调度的关系，可能每次执行打印出1和2的顺序都不一样。
原文地址：http://hi..com/%CD%E6%B5%E7%C4%D4%B5%C4%B7%B2%C8%CB/blog/item/f78ef19967abbe0b6f068c3d.html
⑦ Linux系统中对临界资源进行互斥访问的手段是
自旋锁（Spin Lock）是一种典型的对临界资源进行互斥访问的手段，其名称来源于它的工作方式。为了获得一个自旋锁，在某CPU上运行的代码需先执行一个原子操作，该操作测试并设置（Test-AndSet）某个内存变量。由于它是原子操作，所以在该操作完成之前其他执行单元不可能访问这个内存变量。如果测试结果表明锁已经空闲，则程序获得这个自旋锁并继续执行；如果测试结果表明锁仍被占用，程序将在一个小的循环内重复这个“测试并设置”操作，即进行所谓的“自旋”，通俗地说就是“在原地打转”。当自旋锁的持有者通过重置该变量释放这个自旋锁后，某个等待的“测试并设置”操作向其调用者报告锁已释放。理解自旋锁最简单的方法是把它作为一个变量看待，该变量把一个临界区标记为“我当前在运行，请稍等一会”或者标记为“我当前不在运行，可以被使用。如果A执行单元首先进入例程，它将持有自旋锁；当B执行单元试图进入同一个例程时，将获知自旋锁已被持有，需等到A执行单元释放后才能进入。在ARM体系结构下，自旋锁的实现借用了ldrex指令、strex指令、ARM处理器内存屏障指令dmb和dsb、wfe指令和sev指令，这类似于代码清单7.1的逻辑。可以说既要保证排他性，也要处理好内存屏障。
自旋锁主要针对SMP或单CPU但内核可抢占的情况，对于单CPU和内核不支持抢占的系统，自旋锁退化为空操作。在单CPU和内核可抢占的系统中，自旋锁持有期间中内核的抢占将被禁止。由于内核可抢占的单CPU系统的行为实际上很类似于SMP系统，因此，在这样的单CPU系统中使用自旋锁仍十分必要。另外，在多核SMP的情况下，任何一个核拿到了自旋锁，该核上的抢占调度也暂时禁止了，但是没有禁止另外一个核的抢占调度。尽管用了自旋锁可以保证临界区不受别的CPU和本CPU内的抢占进程打扰，但是得到锁的代码路径在执行临界区的时候，还可能受到中断和底半部的影响。为了防止这种影响，就需要用到自旋锁的衍生。