在多处理器，多线程情况下，如果两个线程分别运行在不同的CPU上，而其中某个线程修改了cache line中的元素，由于cache一致性的原因，另一个线程的cache line被宣告无效，在下一次访问时会出现一次cache line miss，哪怕该线程根本无效改动的这个元素，因此出现了False Sharing问题【1】。
如下图所示，thread1修改了memory灰化区域的第[2]个元素，而Thread0只需要读取灰化区域的第[1]个元素，由于这段memory被载入了各自CPU的硬件cache中，虽然在memory的角度这两种的访问时隔离的，但是由于错误的紧凑地放在了一起，而导致了，thread1的修改，在cache一致性的要求下，宣告了运行Thread0的CPU0的cache line非法，从而出现了一次miss，导致从小从memory中读取到cache line中，而一致性的代价付出了，但结果并不是thread0所care的，导致了效率的降低。关于实验可以参考[2]。
因此在多核编程情况下，要特别注意False Sharing问题。
解决的方法可以是：详细参见【1】
__declspec (align(64)) int thread1_global_variable;
__declspec (align(64)) int thread2_global_variable;
或者是
- struct ThreadParams
- {
- // For the following 4 variables: 4*4 = 16 bytes
- unsigned long thread_id;
- unsigned long v; // Frequent read/write access variable
- unsigned long start;
- unsigned long end;
- // expand to 64 bytes to avoid false-sharing
- // (4 unsigned long variables + 12 padding)*4 = 64
- int padding[12];
- };
- __declspec (align(64)) struct ThreadParams Array[10];
在做多线程程序的时候,为了避免使用锁,我们通常会采用这样的数据结构:根据线程的数目,安排一个数组, 每个线程一个项,互相不冲突. 从逻辑上看这样的设计无懈可击,但是实践的过程我们会发现这样并没有提高速度. 问题在于cpu的cache line. 我们在读主存的时候,数据同时被读到L1,L2中去,而且在L1中是以cache line(通常64)字节为单位的. 每个Core都有自己的L1,L2,所以每个线程在读取自己的项的时候, 也把别人的项读进去, 所以在更新的时候,为了保持数据的一致性, core之间cache要进行同步, 这个会导致严重的性能问题. 这就是所谓的False sharing问题, 有兴趣的同学可以wiki下.
具体的参考文章: http://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads/
解决方法很简单:
把每个项凑齐cache line的长度,实现隔离.
typedef union {
erts_smp_rwmtx_t rwmtx;
byte cache_line_align__[ERTS_ALC_CACHE_LINE_ALIGN_SIZE(
sizeof(erts_smp_rwmtx_t))];
} erts_meta_main_tab_lock_t;
或者
_declspec (align(64)) int thread1_global_variable;
__declspec (align(64)) int thread2_global_variable;
这就是为什么在高性能服务器中到处看到cache_line_align, 号称是避免cache的trash.
类似valgrind和intel vtune的工具可以做这个层次的性能微调.
【1】http://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads/