使thread_local变量完全可变

Question

我正在开发一个使用用户级上下文切换(使用Boost::Context)的运行时库，在使用< code>thread_level变量时遇到了问题。考虑以下(简化的)代码:

thread_local int* volatile tli;

int main()
{
    tli = new int(1);   // part 1, done by thread 1
    UserLevelContextSwitch();
    int li = *tli;      // part 2, done by thread 2
    cout << li;
}

由于对thread_local变量有两个访问，编译器将main函数转换为如下内容（与汇编相反）：

register int** ptli = &tli; // cache address of thread_local variable
*ptli = new int(1);
UserLevelContextSwitch();
int li = **ptli;
cout << li;

这似乎是一种合法的优化，因为易失性 tli 的值没有缓存在寄存器中。但是易失性 tli 的地址实际上是缓存的，而不是从第 2 部分的内存中读取的。

这就是问题所在：在用户级上下文切换之后，执行第1部分的线程将转到其他地方。第2部分随后由其他线程获取，该线程获取先前的堆栈和寄存器状态。但是现在执行第2部分的线程读取属于线程1的tli的值。

我试图找出一种方法来防止编译器缓存线程局部变量的地址，而易失性不够深入。是否有任何技巧（最好是标准的，可能是特定于 GCC 的）来防止线程局部变量地址的缓存？

Answer 1

无法将用户级上下文开关与TLS配对。即使使用原子和全内存Geofence，缓存地址似乎也是合理的优化，因为thread_local变量是文件范围的静态变量，不能像编译器假设的那样移动。（不过，也许有些编译器仍然对编译器内存障碍敏感，比如std:：atomic_thread_fence和asm-volatile（“”：：“memory”） ）

当不同的线程可以在同步点之后继续执行时，cilk-plus使用与您描述的相同的技术来实现“延续窃取”。并且它们明确不鼓励在Cilk程序中使用TLS。相反，他们推荐使用“超对象”Cilk的一个特殊特性，它取代了TLS(还提供了串行/确定性连接语义)。另请参见Cilk开发人员关于< code>thread_local和并行性的演示文稿。

此外，当使用光纤（相同的轻量级上下文切换）时，Windows 提供 FLS（光纤本地存储）作为 TLS 替代品。