考虑以下程序:
#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 上,定义了
TLS_VAR
并执行需要 1.308 秒
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
如果没有
__thread
属性,tls_var
只是一个共享变量。每当一个线程写入时,写入首先会写入线程执行的核心缓存。但由于它是一个共享变量,并且 x86 机器是缓存一致的,因此其他核心的缓存会失效,并且它们的内容会从最后一级缓存或主内存中刷新(在您的情况下很可能是从最后一级缓存中刷新,这是 Core i7 上的共享 L3 缓存)。请注意,虽然比主内存更快,但最后一级缓存并不是无限快 - 它仍然需要大量周期才能将数据从那里移动到 L2 和 L1 缓存,这是每个核心专用的。
使用
__thread
属性,每个线程都会获得自己的 tls_var
副本,位于线程本地存储中。由于这些线程本地存储在内存中彼此相距较远,因此在修改它们时不涉及缓存一致性消息,并且数据保留在最快的 L1 缓存中。
与 RIP
相关的寻址(System V ABI 推荐的用于“近”数据的 x64 默认寻址模式)通常会导致更快的数据访问,但缓存一致性开销非常大,以至于较慢的 TLS 访问实际上在以下情况下会更快:所有内容都保存在 L1 缓存中。
这个问题在 NUMA 系统上被极大地放大,例如在多处理器(后)Nehalem 或 AMD64 板上。保持缓存一致性不仅要昂贵得多,而且共享变量将驻留在附加到套接字的内存中,第一次“接触”该变量的线程就驻留在该内存中。然后,在其他套接字的内核上运行的线程必须通过连接套接字的 QPI 或 HT 总线执行远程内存访问。正如一位客座教授最近所说(粗略的解释):“对共享内存系统进行编程,就好像它们是分布式内存系统一样。”这涉及到要处理的全局数据的本地副本 - 这正是
__thread
属性所实现的目标。
另请注意,无论 TLS 中是否包含
tls_var
,您都应该期待不同的结果。由于它位于 TLS 中,一个线程所做的修改对于其他线程“不可见”。由于它是一个共享变量,您必须确保在给定时间没有超过一个线程可以访问它。这通常是通过关键部分或锁定添加来实现的。