多线程之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就采用另外的空间间隔策略完全避免了这一问题,效果也还不错。





  • 6
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值