多线程之false sharing问题(转)

在多核快速发展的现在，利用多线程技术提高CPU设备的利用率已经成为一种趋势。然而多核计算机体系架构和单核有了很大的变化，在多线程编程中会碰到一些意想不到的问题，比如多核中非常典型的false sharing问题。下文会非常详细的揭示false sharing产生的根源，以及何如避免来提高程序的性能。

        先来了解一下典型的多核架构，每个CPU都有自己的Cache，如果一个内存中的变量在多个Cache中都有副本的话，则需要保证变量的Cache一致性：变量的值为最后一次写入的值。Intel多核架构实现Cache一致性是采用的MESI (Modified/Exclusive/Shared/Invalid) 协议。

     

       以上图为例，初始P1和P2都从Memory中加载变量x=1，这时每个CPU的Cache的x变量均处于Shared状态；当P1写入x=3时，P2中的变量成为无效状态，P1的为Modified状态。以后在P2读取变量x的值，由于P2的Cache的变量x是无效的，致使Cache命中失败，同时系统会用P1的值来更新P2的Cache和Memory，。

 

     

 

      需要注意的是，CPU Cache的结构是按CacheLine为最小单位进行读写的。在Linux可以用命令行sudo cat /proc/cpuinfo看到Cache信息。

本人的机器信息如下：Cache Size： 3072KB， Cache_alignment:64。

    下面的例子就能说明false sharing产生的原因：

double sum=0.0, sum_local[NUM_THREADS];
#pragma omp parallel num_threads(NUM_THREADS)
{
int me = omp_get_thread_num();
sum_local[me] = 0.0;
#pragma omp for
for (i = 0; i < N; i++)
sum_local[me] += x[i] * y[i];  //产生false sharing的代码行
#pragma omp atomic
sum += sum_local[me];
}

      

      在上图中，CPU0和CPU1的sum_local数组位于同一个Cache Line中。比如某个CPU中的线程更新sum_local[]时，会使其他CPU的Cache的sum_local变成Invalid，这样其他CPU中的线程访问该变量的时候就会进行更新，导致Cache失败，这样会造成额外的内存和Cache之间的同步代价。

       在实际的多线程程序中为了避免这种情况，可以采用如下几种方法：

1， 每个线程使用局部线程数据

2， 每个线程访问的全局数据尽可能分隔开至少超过一个Cache Line。

        那么，false sharing对程序性能的影响到底有多大呢？下面通过一个程序来进行的粗略性能实验。

        下面是一个通过蒙特卡洛法来求取pi的值。

#include<stdio.h>
#include<pthread.h>
#include<stdlib.h>
#include<sys/time.h>
#define MaxThreadNum 32
#define kSamplePoints 100000000
#define kSpace 1
void *compute_pi(void *);
inline double WallTime();

int total_hits, hits[MaxThreadNum][kSpace];
int sample_points_per_thread, num_threads;


int main(void)
{
   int i;
   double time_start, time_end;

   pthread_t  p_threads[MaxThreadNum];
   pthread_attr_t attr;

   pthread_attr_init(&attr);
   pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);
   printf("Enter num_threads\n");
   scanf("%d", &num_threads);

   time_start = WallTime();

   total_hits = 0;
   sample_points_per_thread = kSamplePoints / num_threads;

   for(i=0; i<num_threads; i++)
   {
     hits[i][0] = i;
     pthread_create(&p_threads[i], &attr, compute_pi, (void *)&hits[i]);
   }

   for(i=0; i<num_threads; i++)
   {
     pthread_join(p_threads[i], NULL);
     total_hits += hits[i][0];
   }

   double pi = 4.0 * (double)total_hits / kSamplePoints;
   time_end = WallTime();
   printf("Elasped time: %lf, Pi: %lf\n", time_end - time_start, pi);

   return 0;

}

void *compute_pi(void * s)
{
    unsigned int seed;
    int i;
    int *hit_pointer;
    double rand_no_x, rand_no_y;
    int local_hits;

    hit_pointer = (int *)s;
    seed = *hit_pointer;
    local_hits = 0;

    for(i=0; i<sample_points_per_thread; i++)
    {
       rand_no_x = (double)(rand_r(&seed))/(double)(RAND_MAX);
       rand_no_y = (double)(rand_r(&seed))/(double)(RAND_MAX);
       if((rand_no_x - 0.5)*(rand_no_x - 0.5) + (rand_no_y - 0.5) * (rand_no_y - 0.5) < 0.25)
          (*hit_pointer)++;
       // ++local_hits;
       seed *= i;
     }
     //*hit_pointer = local_hits;
     pthread_exit(0);
}

inline double WallTime()
{
    struct timeval tv;
    struct timezone tz;

    gettimeofday(&tv, &tz);

    double currTime =  (double)tv.tv_sec + (double)tv.tv_usec/1000000.0;

    return currTime;
}

        其中注释的代码是一种采用线程局部数据的方法，记为pi_local，改变kSpace可以改变不同的线程访问的全局数据之间的间隔，其中改变kSpace的值使不同线程访问的数据之间的间隔为4bytes， 32bytes，64bytes，并分别记为pi_4, p1_32, pi_64，测试得到的结果如下：

        

 

       因为CPU的数量为2，最大的并行效率为2，以pi_local为标准(因为这种情况完全不存在false sharing问题)，可以看到pi_4的false sharing最为严重，因为16个线程访问的hits数组均位于一个Cache Line，因此会导致严重的Cache Invalid现象。而pi_64就采用另外的空间间隔策略完全避免了这一问题，效果也还不错。