G++ 现在实现了C++11
thread_local关键字；这与 GNU__thread关键字的不同之处主要在于它允许动态初始化和销毁语义。不幸的是，这种支持需要对非函数局部thread_local变量的引用进行运行时惩罚，即使它们不需要动态初始化，所以用户可能希望继续使用__thread具有静态初始化语义的 TLS 变量。
这种运行时惩罚的性质和来源究竟是什么？
显然，为了支持非函数局部thread_local变量，在进入每个线程主线程之前需要一个线程初始化阶段（就像全局变量有一个静态初始化阶段一样），但它们是否指的是一些运行时损失?
粗略的说gcc新实现thread_local的架构是怎样的？
（免责声明：我对 GCC 的内部了解不多，所以这也是一个有根据的猜测。）
thread_local在提交462819c中添加了动态初始化。变化之一是：
* semantics.c (finish_id_expression): Replace use of thread_local
variable with a call to its wrapper.
所以运行时的惩罚是，thread_local变量的每个引用都将成为一个函数调用。让我们用一个简单的测试用例来检查：
// 3.cpp
extern thread_local int tls;
int main() {
tls += 37; // line 6
tls &= 11; // line 7
tls ^= 3; // line 8
return 0;
}
// 4.cpp
thread_local int tls = 42;
编译后*，我们看到引用的每次使用都tls变成了对 的函数调用_ZTW3tls，它懒惰地初始化变量一次：
00000000004005b0 <main>:
main():
4005b0: 55 push rbp
4005b1: 48 89 e5 mov rbp,rsp
4005b4: e8 26 00 00 00 call 4005df <_ZTW3tls> // line 6
4005b9: 8b 10 mov edx,DWORD PTR [rax]
4005bb: 83 c2 25 add edx,0x25
4005be: 89 10 mov DWORD PTR [rax],edx
4005c0: e8 1a 00 00 00 call 4005df <_ZTW3tls> // line 7
4005c5: 8b 10 mov edx,DWORD PTR [rax]
4005c7: 83 e2 0b and edx,0xb
4005ca: 89 10 mov DWORD PTR [rax],edx
4005cc: e8 0e 00 00 00 call 4005df <_ZTW3tls> // line 8
4005d1: 8b 10 mov edx,DWORD PTR [rax]
4005d3: 83 f2 03 xor edx,0x3
4005d6: 89 10 mov DWORD PTR [rax],edx
4005d8: b8 00 00 00 00 mov eax,0x0 // line 9
4005dd: 5d pop rbp
4005de: c3 ret
00000000004005df <_ZTW3tls>:
_ZTW3tls():
4005df: 55 push rbp
4005e0: 48 89 e5 mov rbp,rsp
4005e3: b8 00 00 00 00 mov eax,0x0
4005e8: 48 85 c0 test rax,rax
4005eb: 74 05 je 4005f2 <_ZTW3tls+0x13>
4005ed: e8 0e fa bf ff call 0 <tls> // initialize the TLS
4005f2: 64 48 8b 14 25 00 00 00 00 mov rdx,QWORD PTR fs:0x0
4005fb: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc
400602: 48 01 d0 add rax,rdx
400605: 5d pop rbp
400606: c3 ret
将它与__thread没有这个额外包装器的版本进行比较：
00000000004005b0 <main>:
main():
4005b0: 55 push rbp
4005b1: 48 89 e5 mov rbp,rsp
4005b4: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc // line 6
4005bb: 64 8b 00 mov eax,DWORD PTR fs:[rax]
4005be: 8d 50 25 lea edx,[rax+0x25]
4005c1: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc
4005c8: 64 89 10 mov DWORD PTR fs:[rax],edx
4005cb: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc // line 7
4005d2: 64 8b 00 mov eax,DWORD PTR fs:[rax]
4005d5: 89 c2 mov edx,eax
4005d7: 83 e2 0b and edx,0xb
4005da: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc
4005e1: 64 89 10 mov DWORD PTR fs:[rax],edx
4005e4: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc // line 8
4005eb: 64 8b 00 mov eax,DWORD PTR fs:[rax]
4005ee: 89 c2 mov edx,eax
4005f0: 83 f2 03 xor edx,0x3
4005f3: 48 c7 c0 fc ff ff ff mov rax,0xfffffffffffffffc
4005fa: 64 89 10 mov DWORD PTR fs:[rax],edx
4005fd: b8 00 00 00 00 mov eax,0x0 // line 9
400602: 5d pop rbp
400603: c3 ret
thread_local尽管在每个用例中都不需要这个包装器。这可以从decl2.c. 包装器仅在以下情况下生成：
它不是函数局部的，并且，
extern（上面显示的示例），或__thread），或者__thread变量）。在所有其他用例中，它的行为与__thread. 这意味着，除非您有一些变量，否则您可以在不损失任何性能的情况下extern __thread替换所有变量。__threadthread_local
*：我使用 -O0 编译，因为内联会使函数边界不那么明显。即使我们打开 -O3 ，这些初始化检查仍然存在。
C++11 thread_local 与 __thread 说明符具有相同的运行时效果（__thread不是 C 标准thread_local的一部分；是 C++ 标准的一部分）
这取决于声明 TLS 变量（用__thread说明符声明）的位置。
-fPIC编译器选项编译）并且-ftls-model=initial-exec指定了编译器选项，则访问速度很快；但是存在以下限制：无法通过 dlopen/dlsym（动态加载）加载共享库，使用该库的唯一方法是在编译期间与其链接（链接器选项-l<libraryname>）-fPIC编译器选项集）中声明 TLS 变量，则访问速度非常慢，因为假定了一般动态 TLS 模型 - 这里每次访问 TLS 变量都会导致调用_tls_get_addr()；这是默认情况，因为您不受使用共享库的方式限制。来源：Ulrich Drepper 的线程本地存储的 ELF 处理 https://www.akkadia.org/drepper/tls.pdf 此文本还列出了为支持的目标平台生成的代码。
如果变量是在当前 TU 中定义的，则内联器将处理开销。我希望这对于 thread_local 的大多数用途都是正确的。
对于外部变量，如果程序员可以确定在非定义TU中没有使用该变量需要触发动态初始化（要么是因为变量是静态初始化的，要么是在定义TU中使用该变量之前会执行）在另一个 TU 中的任何用途），他们可以使用 -fno-extern-tls-init 选项避免这种开销。