一个最典型的要使用cpu_relax()锁的场景是忙等待(也就是死循环等一个事情的发生),在内核里面有大量的代码,
比如等寄存器状态:
比如做延迟:
简单来说,你如果在内核里面写了忙等待的代码,都没有在循环里面加个cpu_relax()的话,这基本上是一种比较幼稚的表现。
根据内核文档volatile-considered-harmful,cpu_relax()的描述:
由此可见cpu_relax()至少具备三大功能:
1, 帮着省电;
2, 如果是超线程CPU的机器,可以让渡CPU给其他的线程;因为我这个CPU目前没什么正经事情干,等的时间不如放慢节奏,让别人多干点;
3, 它是一个编译屏障,让volatile变地在内核基本没什么必要。
当然,cpu_relax()的具体实现与体系架构相关,不同的体系架构实现不一样,可能只完成了上面3个功能中的1个,2个而不是全部。
我们看看它在ARM64的实现:
其中"memory"的部分是服务于屏障功能,而前面的yield符合SMT系统让渡的语义。在典型的超线程处理器中,每个超线程不是一个独立的core,所以两个或者多个超线程之间仍然在竞争一些资源,如果其中一个人调用了yield,那么它会在争抢中放慢节奏,而旁边的那个兄弟会抢地更多。
PowerPC的实现则是调节hardware multi-threading的优先级:
当然,硬件如果不具备这种超线程能力的话,cpu_relax()可以简单地是一个编译屏障,
#define cpu_relax() barrier()
比如 arch/alpha/include/asm/processor.h 中:
REP NOP这种pause操作既可以省点,有可以避免忙等的CPU疯狂去抢总线访问内存。如果纯粹地不加pause暗示的忙等,疯狂执行指令,应该是很耗电的,忙等中拼命访问内存,总线冲突也大。
总之,不管具体的体系架构怎么实现,忙等里面都适合加cpu_relax(),毕竟内核多数的代码要求是跨平台的。