WebAssembly：线程安全和 C/C++ 局部变量

Question

我试图理解 WebAssembly 内存模型，特别是从以下角度：在 WebAssembly 实例之间共享线性内存时我会面临什么样的风险？所有 C/C++ => wasm 教程给我们的基本内存模型如下（堆栈以__heap_base - 1 开头并向下增长）：

+-----------------------------------------------+
| ? | static data |     stack     |     heap    |
+-----------------------------------------------+
^   ^             ^               ^             ^
|   |             |               |             |
0 __global_base  __data_end     __heap_base  MAX_MEMORY

但以下事实让我感到惊讶。来自https://webassembly.org/docs/security/：

具有不明确静态范围的局部变量（例如，由地址运算符使用，或者是结构类型并按值返回）在编译时存储在线性内存中单独的用户可寻址堆栈中。这是一个独立的内存区域，具有固定的最大大小，默认初始化为零。

来自https://github.com/WebAssembly/design/blob/main/Rationale.md#locals：

C/C++ 可以获取函数的本地值的地址并将此指针传递给被调用者或其他线程。由于 WebAssembly 的局部变量位于地址空间之外，因此 C/C++ 编译器通过在线性内存中创建单独的堆栈数据结构来实现地址获取变量。这个堆栈有时被称为“别名”堆栈，因为它用于可能被指针指向的变量。

换句话说，从__heap_base - 1 到__data_end 定义的堆栈是C/C++ 编译模块的实现工件。 “WASM 堆栈”位于线性内存之外。碰巧的是，当您获取本地地址（例如）时，编译器将其存储在“别名堆栈”中，因此需要获取地址。

在使用共享内存的情况下，这种行为是否会引发新的非常危险的数据竞争？

想象这样一段代码：

int calculation(int param1, int param2)
{
    if (param1 == param2 * 2)
        ++param1;
    else
        ++param2;

    return param1 / 3 + param2;
}

这里，calculation 是线程安全的。但是，如果我用这种等效形式替换 calculation：

int calculation(int param1, int param2)
{
    int* param = param1 == param2 * 2 ? &param1 : &param2;

    ++*param;

    return param1 / 3 + param2;
}

根据编译器的输出，calculation 可能不再是线程安全的，以防param1 和/或param2 存储在别名堆栈上，该别名堆栈位于线性内存中，可以与其他内存共享--features=atomics,bulk-memory --shared-memory 标志启用共享内存的实例。

那么，在哪些具体情况下编译器可以决定将局部变量存储在别名堆栈上？

编辑：我做了一些测试来验证，我想知道我是否正确。我在堆上存储了使用 16 个无符号局部变量的函数的第一个、一半和最后一个局部变量的内存地址，我从 javascript 中将它们打印出来，以及最低存储地址与 @987654335 之间的差异@ 是32*3 bytes + padding，而不是32*16 + padding，这意味着只有内存地址被占用的三个变量存储在别名堆栈中。当然，这些测试不是线程安全的，因为我将本地人的地址存储在函数之外，但它说明了一点：如果在可重入函数上，我暂时获取本地人的地址来实现方便，并且由于其复杂性，编译器不确定我要做什么，它最终可以决定将本地存储在堆栈上而不是更改其实现，从而使函数线程不安全。

Answer 1

在多线程设置中，每个线程都会将自己的堆栈放入共享内存中。堆栈指针（它的创建 seems to be done by LLVM createSyntheticSymbols）被放置到 WebAssembly global 变量中。目前这些全局变量用作thread-local storage。这意味着每个线程都有自己的全局变量。

在 WebAssembly 实例开始时，主线程将有自己的全局变量指向共享内存中的主线程堆栈。如果您启动另一个线程，在它的启动期间，它的全局变量将指向共享内存中的另一个位置，该位置放置该线程的堆栈。

如果调用者不提供自己的指针，则分配堆栈seems to be done by Emscripten __pthread_create_js。将变量分配到当前堆栈中完成here with stackAlloc 其中：

global.get __stack_pointer

正在获取当前线程堆栈指针，减去所需的字节（堆栈向下增长），将其对齐为 16 个字节，然后将新值记忆回全局。这都是线程安全的，因为全局只能从线程本身访问。

关于指针，是的，编译器会将指针访问的变量放入显式堆栈中。目前 WebAssembly 堆栈不是“可步行的”，但有一个 proposal 可以做到这一点。许多实现还使用显式堆栈，以获得对堆栈使用（变量、结构等）的更细粒度的控制。

所有这些“东西”都应该(RFC 2119) 对开发人员透明。意思是，它似乎可以正常工作。

---

基于您的 cmets：此时的 WebAssembly 标准通过使用原子指令来处理数据竞争。他们的访问顺序是sequentially consistent。在多线程的情况下，显然内存分配器必须是线程安全的。不必单独使用显式线程专用堆栈（使用全局变量就足够了，如前所述），因为堆栈内存仅由线程本身管理。检查the threads proposal 的原子指令和implementation status。也允许在非共享内存中使用原子指令。

---

某些实现在进行非原子访问和原子访问时可能会锁定整个内存。这至少是因为规范不禁止更高的内存访问保证。这意味着即使您在某个内存地址创建竞争，您也无法读取不一致/撕裂的值。但是，这只是一种不应该依赖的可能性。

Answer 2

WASM 做出的选择并不少见。拆分堆栈和多堆栈设计并不新鲜，并且一直与 C 和 C++ 兼容。这是 C 规范不足的故意结果，它始终允许“堆栈”变量存在于不可寻址的寄存器中。 C 堆栈是抽象的，与底层执行环境的关系有限。

当 C++ 采用 C++11 的 Java 内存模型（C 紧随其后）时，线程安全并不是“自动的”，而是仅适用于 C++ 对象。从这个意义上说，“堆”不是一个对象，而是一个概念，实现安全是实现的责任。请注意，C++ 标准不需要性能。技术上允许使用全局锁来保护堆。

在这种情况下，这意味着 WASM 应该将单独的堆栈分开（正如 @Nikolay 指出的那样）。这些堆栈占用的内存区域无关紧要，只要各个堆栈的各个片段在任何特定时刻不重叠即可。