linux2.6内核编程培训.ppt

汇报结束，请提意见和建议 * * * * * 信号量（2） 你可以在持有信号量时去睡眠（当然你也可能并不需要睡眠），因为当其他进程试图获得同一信号量时不会因此而死锁（因为该进程也只是去睡眠而已，而你最终会继续执行的）。 在你占用信号量的同时不能占用自旋锁。因为在你等待信号量时可能会睡眠，而在持有自旋锁时是不允许睡眠的。 如果需要在自旋锁和信号量中做选择，应该根据锁被持有的时间长短做判断。同时在中断上下文中只能使用自旋锁，而在任务睡眠时只能使用信号量。 另外，信号量不同于自旋锁，它不会禁止内核抢占，所以持有信号量的代码可以被抢占。这意味着信号量不会对调度的等待时间带来负面影响。 信号量有一个有用的特性，它可以同时允许任意数量的锁持有者，而自旋锁在一个时刻最多允许一个任务持有它。信号量同时允许的持有者数量可以在声明信号量时指定。 流水线的处理 流水线对于单核和多核处理的方式都一样。 现代处理器，为了加快处理速度，使用了流水线处理方法，但流水线处理方法会带来数据冒险（当一条指令用到的数据被前面流水线中指令改变的话，就会出现冒险）。CPU利用数据前递（将结果值直接从一个流水线阶段传到较早阶段的技术）和加载互锁（用暂停来处理加载/使用冒险的方法）来解决流水线数据冒险问题。 对于应用程序来说，可以不用关注流水线问题（无论是单核还是多核），不需要使用任何机制保证它的正确性（对于软件是透明的），因为CPU会处理的很好。 缓存一致性（1） 为了提高数据访问效率，每个CPU上都有一个容量很小（现在一般是2M这个数量级），速度很快的缓存，用于缓存最常访问的那些数据。由于操作内存的速度实在太慢，数据被修改时也只更新缓存，并不直接写出到内存中去，这一来就造成了缓存中的数据与内存不一致。 单核：如果系统中只有一个CPU，所有线程看到的都是缓存中的必威体育精装版数据，这就不存在一致性问题。 多核：但如果系统中有多个CPU，同一份内存可能会被缓存到多个CPU中，如果在不同CPU中运行的不同线程看到同一份内存的缓存值不一样就麻烦了，因此有必要维护这多种缓存的一致性。当然要做到这一点只要一有修改操作，就通知所有CPU更新缓存，或者放弃缓存下次访问的时候再重新从内存中读取。但这个Stupid的实现显然不会有好的性能，为解决这一问题，产生了很多维护缓存一致性的协议，MESI就是其中一种。 缓存一致性 MESI协议的名称由来是指这一协议为缓存的每个数据单位（称为cache line，在Intel CPU上一般是64字节）维护两个状态位，使得每个数据单位可能处于M、E、S或I这四种状态之一。各种状态含义如下： M: 被修改的。处于这一状态的数据只在本CPU中有缓存，且其数据已被修改，没有更新到内存中 E: 独占的。处于这一状态的数据只在本CPU中有缓存，且其数据没有被修改，与内存一致 S: 共享的。处于这一状态的数据在多个CPU中有缓存 I: 无效的。本CPU中的这份缓存已经无效了。 缓存一致性 当CPU要读取数据时，只要缓存的状态不是I都可以从缓存中读，否则就要从主存中读。这一读操作可能会被某个处于M或E状态的CPU截获，该CPU将修改的数据写出到内存，并将自己设为S状态后这一读操作才继续进行。只有缓存状态是E或M时，CPU才可以修改其中的数据，修改后缓存即处于M状态。如果CPU要修改数据时发现其缓存不处于E或M状态，则需要发出特殊的RFO指令（Read For Ownership），将其它CPU的缓存设为I状态。因此，如果一个变量在某段时间内只被一个线程频繁修改，则对应的缓存早就处于M状态，这时CAS操作就不会涉及到总线操作。所以频繁的加锁并不一定会影响系统并发度，关键是看锁冲突的情况严重不严重，如果经常出现冲突，即缓存一会被这个CPU独占，一会被那个CPU独占，这时才会不断产生RFO，影响到并发性能。 结论：在SMP结构中，多个CPU之间缓存一致性问题对于软件而言是透明的，应用程序可以不用关注缓存一致性问题。 优化屏障和内存屏障（1） 当处理多处理器之间或处理器与硬件设备之间的同步问题时，有时需要在你的程序代码中以指定的顺序发出读内存（读入）和写内存（存储）指令，这时就要考虑到屏障，其它情况不需考虑。 优化屏障：当使用优化编译器时，你千万不要认为指令会严格按它们在源代码中出现的顺序执行。例如，编译器可能重新安排汇编语言指令以使寄存器以最优的方式使用。优化屏障原语保证编译程序不会混淆放在原语操作之前的汇编语言指令和放在原语操作之后的汇编语言指令，它可以防止编译器跨屏障对载入或存储操作进行优化。同时使编译器不会重新组织存储或载入操作而防止改变C代码的效果和现有数据的依赖关系。 在linux中，优化屏障就是barrier()宏，它展开为asm volati