Linux 提出了 Multi-Processing 的概念，它的调度器可以将操作系统的线程均分到各个核（或硬件线程）上去执行，以此达到并行计算的目的，从而也可以极大地提高系统的性能。

实现计数器

 1)自旋锁 

spinlock不会导致线程的状态切换(用户态->内核态)，

1， spinlock介绍

　　spinlock又称自旋锁，线程通过busy-wait-loop的方式来获取锁，任时刻只有一个线程能够获得锁，其他线程忙等待直到获得锁。spinlock在多处理器多线程环境的场景中有很广泛的使用，一般要求使用spinlock的临界区尽量简短，这样获取的锁可以尽快释放，以满足其他忙等的线程。Spinlock和mutex不同，spinlock不会导致线程的状态切换(用户态->内核态)，但是spinlock使用不当(如临界区执行时间过长)会导致cpu busy飙高。

　　2， spinlock与mutex对比

　　2.1，优缺点比较

　　spinlock不会使线程状态发生切换，mutex在获取不到锁的时候会选择sleep。

　　mutex获取锁分为两阶段，第一阶段在用户态采用spinlock锁总线的方式获取一次锁，如果成功立即返回；否则进入第二阶段，调用系统的futex锁去sleep，当锁可用后被唤醒，继续竞争锁。

　　Spinlock优点：没有昂贵的系统调用，一直处于用户态，执行速度快。

　　Spinlock缺点：一直占用cpu，而且在执行过程中还会锁bus总线，锁总线时其他处理器不能使用总线。

　　Mutex优点：不会忙等，得不到锁会sleep。

　　Mutex缺点：sleep时会陷入到内核态，需要昂贵的系统调用。

　　2.2，使用准则

　　Spinlock使用准则：临界区尽量简短，控制在100行代码以内，不要有显式或者隐式的系统调用，调用的函数也尽量简短。例如，不要在临界区中调用read,write,open等会产生系统调用的函数，也不要去sleep；strcpy，memcpy等函数慎用，依赖于数据的大小。

　　3， spinlock系统实现

　　spinlock的实现方式有多种，但是思想都是差不多的，现罗列一下：

　　3.1，glibc-2.9中的实现方法：

　　执行过程：

　　1，lock_prefix 即 lock。lock decl %0，锁总线将%0(即lock变量)减一。Lock可以保证接下来一条指令的原子性。

　　2， 如果lock=1，decl的执行结果为lock=0，ZF标志位为1，直接跳到return 0；否则跳到标签2。也许要问，为啥能直接跳到return 0呢？因为subsection和previous之间的代码被编译到别的段中，因此jne之后紧接着的代码就是 return 0 (leaveq;retq)。Rep nop在经过编译器编译之后被编译成 pause。

　　3， 如果跳到标签2，说明获取锁不成功，循环等待lock重新变成1，如果lock为1跳到标签1重新竞争锁。

　　该实现采用的是AT&T的汇编语法，更详细的执行流程解释可以参考“五竹”大牛的文档。

TAS: 指Test-And-Set，它是一个原子操作，修改内存的值，并返回原来的值

http://blog.itpub.net/30088583/viewspace-1512121/

http://blog.csdn.net/yuanrxdu/article/details/41170381

#include <stdio.h>
#include <stdlib.h>

int test_and_set(volatile int *addr){
    int old_value;
    old_value=swap_atomic(addr,1);
    if(old_value == 0){
        return 0;
    }
    return 1;
}

void spin_lock(volatile lock_t* lock_status)
{
    while (test_and_set(lock_status) ==1)
    ;
}

void unlock(volatile *lock_status){
    *lock_status=0;
}



int main(){
    lock_t* lock_status=0;
    int count=0;
    spin_lock(lock_status);
    count++;
    spin_unlock(lock_status);
    return 0;
}

现在有两颗CPU CPU1和CPU2,同时运行上面程序

当运行完 

lock_t *lock_status后，CPU1和CPU2的高速缓冲中都存放了0

执行spin_lock后，CPU1先拿到了锁（swap_aotime(addr,1) 所做的汇编为

　　lock bus;

     movl $1,%eax;将1放进寄存器eax

　　movl %eax,addr;将寄存器的值放入addr所在的内存     

）此时,内存中lock_status的值为1，同时,CPU1向总线发出广播，说CPU1改变了lock_status的值，CPU2收到通知后,将高速缓冲中的lock_status的状态置为invalid

当CPU2执行spin_lock时,因为CPU2的高速缓冲中的lock_status标志为invalid,所以CPU2会向总线发一个通知，CPU1接收通知后,将lock_status=1推向CPU2的调整缓存，并将值写入主存中，因为 1!=0  所以拿不到锁,只能忙等待,耗费CPU

　　更精确的cache实现需要考虑到其他更多的可能性，比如第二个CPU在读或者写他的cache line时，发现该cache line在第一个CPU的cache中被标记为脏数据了，此时我们就需要做进一步的处理。在这种情况下，主存储器已经失效，第二个CPU需要读取第一个CPU的cache line。通过测试，我们知道在这种情况下第一个CPU会将自己的cache line数据自动发送给第二个CPU。这种操作是绕过主存储器的，但是有时候存储控制器是可以直接将第一个CPU中的cache line数据存储到主存储器中。对第一个CPU的cache的写访问会导致本地cache line的所有拷贝被标记为无效。

用TAS来实现spin lock,此处要注意volatile的使用。volatile表示这个变量是易失的，所以会编译器会每次都去内存中取原始值，而不是直接拿寄存器中的值。

这避免了在多线程编程中，由于多个线程更新同一个变更，内存中和寄存器中值的不同步而导致变量的值错乱的问题。另外，也会影响编译器的优化行为。

 http://m.blog.csdn.net/blog/gigglesun/37595689

  http://blog.csdn.net/robertsong2004/article/details/38340247

自旋锁是一种非阻塞锁，也就是说，如果某线程需要获取自旋锁，但该锁已经被其他线程占用时，该线程不会被挂起，而是在不断的消耗CPU的时间，不停的试图获取自旋锁。

互斥量是阻塞锁，当某线程无法获取互斥量时，该线程会被直接挂起，该线程不再消耗CPU时间，当其他线程释放互斥量后，操作系统会激活那个被挂起的线程，让其投入运行。

两种锁适用于不同场景：

如果是多核处理器，如果预计线程等待锁的时间很短，短到比线程两次上下文切换时间要少的情况下，使用自旋锁是划算的。

如果是多核处理器，如果预计线程等待锁的时间较长，至少比两次线程上下文切换的时间要长，建议使用互斥量。

如果是单核处理器，一般建议不要使用自旋锁。因为，在同一时间只有一个线程是处在运行状态，那如果运行线程发现无法获取锁，只能等待解锁，但因为自身不挂起，所以那个获取到锁的线程没有办法进入运行状态，只能等到运行线程把操作系统分给它的时间片用完，才能有机会被调度。这种情况下使用自旋锁的代价很高。

如果加锁的代码经常被调用，但竞争情况很少发生时，应该优先考虑使用自旋锁，自旋锁的开销比较小，互斥量的开销较大。

单CPU情况下,

线程A取得锁,这时线程B尝试获得锁,得不到,不停向CPU发起请求,

线程A得不到CPU，即使想释放锁,也不行，因为CPU使用权在线程B

当CPU分给线程A的时间片用完,线程A也释放了锁,线程B在时间片范围内即可拿到锁

可见,单CPU下面的自旋锁浪费了好多时间

上面的TAS有一个问题 ,当某个线程拿不到锁时,会不停的执行while(test_and_set(lock_status)==1),这个lock_status是volatile修饰符，这就需要不停的经过总线，向内存取数据，可能造成总线风暴，于是出现了TTAS

TAS

void spin_lock(volatile int* lock_status){

　　while(test_and_set(lock_status) == 1)

　　;

}

TTAS

void spin_lock(volatile int* lock_status){     //volatile 表示从内存取数据

　　while(test_and_set(lock_status) == 1) //然后放入CPU高速缓存中

　　　　while(lock_status) //在高速缓存中循环,不会消耗总线资源,当持锁的线程解锁后，这里的数据变成invalid,再向内存读数据, 加锁成功

           //http://my.oschina.net/clopopo/blog/140479

}

 改进

http://blog.csdn.net/david_henry/article/details/5405093/

 http://blog.csdn.net/robertsong2004/article/details/38340247

 http://www.cnblogs.com/dolphin0520/p/3920373.html

 http://blog.csdn.net/liu251/article/details/6439453

http://my.oschina.net/clopopo/blog/140479