资讯类网站模板asp,欧美跨境电商平台有哪些,装饰网站案例,网站开发与微信对接转自#xff1a;http://www.linuxidc.com/Linux/2011-10/44623.htm 前言之前读了关于顺序一致性和缓存一致性讨论的文章#xff0c;感觉豁然开朗。对linux内核中出现的种种同步和屏障#xff0c;想做一点总结。 缓存一致性之前一直认为linux中很多东西是用来保证缓存一致性的…转自http://www.linuxidc.com/Linux/2011-10/44623.htm 前言之前读了关于顺序一致性和缓存一致性讨论的文章感觉豁然开朗。对linux内核中出现的种种同步和屏障想做一点总结。 缓存一致性之前一直认为linux中很多东西是用来保证缓存一致性的其实不是。缓存一致性绝大部分是靠硬件机制实现的只有在带lock前缀的指令执行时才与cache有一点关系。这话说得绝对但我目前看来就是这样我们更多的时候是为了保证顺序一致性。- 所谓缓存一致性就是在多处理器系统中每个cpu都有自己的L1 cache。很可能两个不同cpu的L1 cache中缓存的是同一片内存的内容如果一个cpu更改了自己被缓存的内容它要保证另一个cpu读这块数据时也要读到这个最新的。不过你不要担心这个复杂的工作完全是由硬件来完成的通过实现一种MESI协议硬件可以轻松的完成缓存一致性的工作。不要说一个读一个写就是多个同时写都没问题。一个cpu读时总能读入最新的数据不管它是在自己的cache中还是在其它cpu的cache中还是在内存中这就是缓存一致性。 顺序一致性所谓顺序一致性说的则是与缓存一致性完全不同的概念虽然它们都是处理器发展的产物。因为编译器的技术不断发展它可能为了优化你的代码而将某些操作的顺序更改执行。处理器中也早就有了多发射、乱序执行的概念。这样的结果就是实际执行的指令顺序会与编程时代码的执行顺序略有不同。这在单处理器下当然没什么毕竟只要自己的代码不过问就没人过问编译器和处理器就是在保证自己的代码发现不了的情况下打乱执行顺序的。但多处理器不是这样可能一个处理器上指令的完成顺序会对其它处理器上执行的代码造成很大影响。所以就有了顺序一致性的概念即保证一个处理器上线程的执行顺序在其它的处理器上的线程看来都是一样的。这个问题的解决不是光靠处理器或者编译器就能解决的需要软件的干预。 内存屏障软件干预的方式也非常简单那就是插入内存屏障(memory barrier)。其实内存屏障这个词是由搞处理器的人造的弄得我们很不好理解。内存屏障很容易让我们串到缓存一致性去乃至怀疑是否这样做才能让其它cpu看到被修改过的cache这样想就错了。所谓内存屏障从处理器角度来说是用来串行化读写操作的从软件角度来讲就是用来解决顺序一致性问题的。编译器不是要打乱代码执行顺序吗处理器不是要乱序执行吗你插入一个内存屏障就相当于告诉编译器屏障前后的指令顺序不能颠倒告诉处理器只有等屏障前的指令执行完了屏障后的指令才能开始执行。当然内存屏障能阻挡编译器乱来但处理器还是有办法。处理器中不是有多发射、乱序执行、顺序完成的概念吗它在内存屏障时只要保证前面指令的读写操作一定在后面指令的读写操作完成之前完成就可以了。所以内存屏障才会对应有读屏障、写屏障和读写屏障三类。如x86之前保证写操作都是顺序完成的所以不需要写屏障但现在也有部分ia32处理器的写操作变成乱序完成所以也需要写屏障。 其实除了专门的读写屏障指令还有很多指令的执行是带有读写屏障功能的比如带lock前缀的指令。在专门的读写屏障指令出现之前linux就是靠lock熬过来的。 至于在那里插入读写屏障要视软件的需求而定。读写屏障无法完全实现顺序一致性但多处理器上的线程也不会一直盯着你的执行顺序看只要保证在它看过来的时候认为你符合顺序一致性执行不会出现你代码中没有预料到的情况。所谓预料外的情况举例而言你的线程是先给变量a赋值再给变量b赋值结果别的处理器上运行的线程看过来发现b赋值了a却没有赋值注意这种不一致不是由缓存不一致造成的而是处理器写操作完成的顺序不一致造成的这时就要在a赋值与b赋值之间加一个写屏障。 多处理器间同步 有了SMP之后线程就开始同时在多个处理器上运行。只要是线程就有通信和同步的要求。幸好SMP系统是共享内存的也就是所有处理器看到的内存内容都一样虽然有独立的L1 cache但还是由硬件完成了缓存一致性处理的问题。那不同处理器上的线程要访问同一数据需要临界区需要同步。靠什么同步之前在UP系统中我们上靠信号量下靠关中断和读修改写指令。现在在SMP系统中关中断已经废了虽然为了同步同一处理器上的线程还是需要的但只靠它已经不行了。读修改写指令也不行了。在你指令中读操作完成写操作还没进行时就可能有另外的处理器进行了读操作或者写操作。缓存一致性协议是先进但还没有先进到预测这条读操作是哪种指令发出来的。所以x86又发明了带lock前缀的指令。在此指令执行时会将所有包含指令中读写地址的cache line失效并锁定内存总线。这样别的处理器要想对同样的地址或者同一个cache line上的地址读写既无法从cache中进行cache中相关line已经失效了也无法从内存总线上进行整个内存总线都锁了终于达到了原子性执行的目的。当然从P6处理器开始如果带lock前缀指令 要访问的地址本来就在cache中就无需锁内存总线也能完成原子性操作了虽然我怀疑这是因为加了多处理器内部公共的L2 cache的缘故。 因为会锁内存总线所以带lock前缀指令执行前也会先将未完成的读写操作完成也起到内存屏障的功能。 现在多处理器间线程的同步上用自旋锁下用这种带了lock前缀的读修改写指令。当然实际的同步还有加上禁止本处理器任务调度的有加上任务关中断的还会在外面加上信号量的外衣。linux中对这种自旋锁的实现已历经四代发展变得愈发高效强大。 内存屏障的实现#ifdef CONFIG_SMP #define smp_mb() mb() #define smp_rmb() rmb() #define smp_wmb() wmb() #else #define smp_mb() barrier() #define smp_rmb() barrier() #define smp_wmb() barrier() #endif CONFIG_SMP就是用来支持多处理器的。如果是UP(uniprocessor)系统就会翻译成barrier()。 #define barrier() __asm__ __volatile__(: : :memory) barrier()的作用就是告诉编译器内存的变量值都改变了之前存在寄存器里的变量副本无效要访问变量还需再访问内存。这样做足以满足UP中所有的内存屏障。 #ifdef CONFIG_X86_32 /* * Some non-Intel clones support out of order store. wmb() ceases to be a * nop for these. */ #define mb() alternative(lock; addl $0,0(%%esp), mfence, X86_FEATURE_XMM2) #define rmb() alternative(lock; addl $0,0(%%esp), lfence, X86_FEATURE_XMM2) #define wmb() alternative(lock; addl $0,0(%%esp), sfence, X86_FEATURE_XMM) #else #define mb() asm volatile(mfence:::memory) #define rmb() asm volatile(lfence:::memory) #define wmb() asm volatile(sfence ::: memory) #endif 如果是SMP系统内存屏障就会翻译成对应的mb()、rmb()和wmb()。这里CONFIG_X86_32的意思是说这是一个32位x86系统否则就是64位的x86系统。现在的linux内核将32位x86和64位x86融合在同一个x86目录所以需要增加这个配置选项。 可以看到如果是64位x86肯定有mfence、lfence和sfence三条指令而32位的x86系统则不一定所以需要进一步查看cpu是否支持这三条新的指令不行则用加锁的方式来增加内存屏障。 SFENCE,LFENCE,MFENCE指令提供了高效的方式来保证读写内存的排序,这种操作发生在产生弱排序数据的程序和读取这个数据的程序之间。 SFENCE——串行化发生在SFENCE指令之前的写操作但是不影响读操作。 LFENCE——串行化发生在SFENCE指令之前的读操作但是不影响写操作。 MFENCE——串行化发生在MFENCE指令之前的读写操作。 sfence:在sfence指令前的写操作当必须在sfence指令后的写操作前完成。 lfence在lfence指令前的读操作当必须在lfence指令后的读操作前完成。 mfence在mfence指令前的读写操作当必须在mfence指令后的读写操作前完成。 至于带lock的内存操作会在锁内存总线之前就把之前的读写操作结束功能相当于mfence当然执行效率上要差一些。 说起来现在写点底层代码真不容易既要注意SMP问题又要注意cpu乱序读写问题还要注意cache问题还有设备DMA问题等等。 多处理器间同步的实现 多处理器间同步所使用的自旋锁实现已经有专门的文章介绍见《spin lock在kernel 2.4与2.6中的实现与改进》。 本篇文章来源于 Linux公社网站(www.linuxidc.com) 原文链接http://www.linuxidc.com/Linux/2011-10/44623.htm
