3

考虑以下程序：

#include <pthread.h>

static int final_value = 0;

#ifdef TLS_VAR
static int __thread tls_var;
#else
static int tls_var;
#endif

void  __attribute__ ((noinline)) modify_tls(void) {
  tls_var++;
}

void *thread_function(void *unused) {
  const int iteration_count = 1 << 25;

  tls_var = 0;
  for (int i = 0; i < iteration_count; i++) {
    modify_tls();
  }
  final_value += tls_var;
  return NULL;
}

int main() {
  const int thread_count = 1 << 7;

  pthread_t thread_ids[thread_count];
  for (int i = 0; i < thread_count; i++) {
    pthread_create(&thread_ids[i], NULL, thread_function, NULL);
  }

  for (int i = 0; i < thread_count; i++) {
    pthread_join(thread_ids[i], NULL);
  }

  return 0;
}

在我的 i7 上，执行定义需要 1.308 秒，TLS_VAR未定义执行需要 8.392 秒；我无法解释如此巨大的差异。

的组件modify_tls看起来像这样（我只提到了不同的部分）：

;; !defined(TLS_VAR)
movl tls_var(%rip), %eax
addl $1, %eax
movl %eax, tls_var(%rip)

;; defined(TLS_VAR)
movl %fs:tls_var@tpoff, %eax
addl $1, %eax
movl %eax, %fs:tls_var@tpoff

TLS 查找是可以理解的，有来自 TCB 的负载。但是为什么tls_var第一种情况下的负载相对于%rip？为什么它不能是由加载器重定位的直接内存地址？这种%rip相对负载是造成缓慢的原因吗？如果是这样，为什么？

编译标志：gcc -O3 -std=c99 -Wall -Werror -lpthread

4

1 回答 1

4

没有__thread属性tls_var只是一个共享变量。每当一个线程写入它时，写入首先会进入线程执行的核心缓存。但是由于它是一个共享变量并且 x86 机器是缓存一致的，因此其他内核的缓存会失效，并且它们的内容会从最后一级缓存或主内存中刷新（在你的情况下很可能来自最后一级缓存，这是 Core i7 上的共享 L3 缓存）。请注意，虽然比主内存快，但最后一级缓存并不是无限快的——它仍然需要很多周期才能将数据从那里移动到每个内核私有的 L2 和 L1 缓存。

使用该__thread属性，每个线程都有自己的副本tls_var，位于线程本地存储中。由于这些线程本地存储在内存中彼此相距很远，因此在修改它们时不涉及缓存一致性消息，并且数据保留在最快的 L1 缓存中。

RIP-related 寻址（System V ABI 推荐的用于“近”数据的 x64 默认寻址模式）通常会导致更快的数据访问，但缓存一致性开销如此巨大，以至于当所有内容都保存在中时，较慢的 TLS 访问实际上更快一级缓存。

这个问题在 NUMA 系统上被大大放大，例如在多处理器（后）Nehalem 或 AMD64 板上。不仅保持缓存一致的成本要高得多，而且共享变量将驻留在内存中，连接到套接字，第一次“接触”该变量的线程所在的位置。然后，在来自其他套接字的内核上运行的线程必须通过连接套接字的 QPI 或 HT 总线执行远程内存访问。正如一位客座教授最近所说（粗略的解释）：“对共享内存系统进行编程，就好像它们是分布式内存系统一样。” 这涉及制作全局数据的本地副本以进行处理——这正是该__thread属性所实现的。

另请注意，无论tls_var是否在 TLS 中，您都应该期待不同的结果。由于它在 TLS 中，一个线程所做的修改对其他线程不可见。由于它是一个共享变量，因此您必须确保在给定时间只有一个线程可以访问它。这通常通过关键部分或锁定添加来实现。

于 2012-12-03T20:02:50.203 回答