我正在嘗試理解 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 - 1to定義的堆疊__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 ? ¶m1 : ¶m2;
*param;
return param1 / 3 param2;
}
Depending on compiler's output, calculation could no longer be thread-safe in case param1 and/or param2 are stored on the aliased-stack, which lives on the linear memory, which could be shared among other instances if shared memory is enabled by the --features=atomics,bulk-memory --shared-memory flags.
So, in which exact situations can the compiler decide to store a local variable on the aliased-stack?
EDIT: I did some tests to verify, and I would like to know if I'm right on this. I stored, on the heap, the memory addresses of the first, the half and the last local variables of a function that use 16 unsigned local variables, and I print them out from javascript, and the difference between the lowest stored address to __heap_base was 32*3 bytes padding, and not 32*16 padding, which means that only the three variables whose memory address was taken was stored on the aliased-stack. Of course, these tests are not thread-safe because I'm storing the addresses of locals outside the function, but it illustrates the point: if, on a re-entrant function, I'm temporarily taking the address of a local for implementation convenience, and, because of its complexity, the compiler isn't sure about what I'm trying to do, it could finally decide to store the local on the stack instead of changing its implementation, turning the function thread-unsafe.
uj5u.com熱心網友回復：
在多執行緒設定中，每個執行緒都會將自己的堆疊放入共享記憶體中。堆疊指標（它的創建似乎是由 完成的LLVM createSyntheticSymbols）被放置到一個 WebAssembly全域變數中。目前這些全域變數被用作執行緒本地存盤。這意味著每個執行緒都有自己的全域變數。
在 WebAssembly 實體開始時，主執行緒會有自己的全域變數指向共享記憶體中的主執行緒堆疊。如果您啟動另一個執行緒，在其啟動期間，其全域變數將指向共享記憶體中的另一個位置，該位置放置該執行緒的堆疊。
如果呼叫者不提供自己的指標，則堆疊的分配似乎已完成Emscripten __pthread_create_js。變數到當前堆疊的分配在這里stackAlloc完成：
global.get __stack_pointer
正在獲取當前執行緒堆疊指標，減去所需的位元組（堆疊向下增長），將其對齊到 16 個位元組，然后將新值記住回全域。這是所有執行緒安全的，因為全域只能從執行緒本身訪問。
關于指標，是的，編譯器會將指標訪問的變數放入顯式堆疊中。目前 WebAssembly 堆疊不是“可行走的”，但有一個建議可以做到這一點。許多實作還額外使用顯式堆疊，以對堆疊使用（變數、結構等）進行更細粒度的控制。
所有這些“東西”應在（RFC 2119）是透明的開發者。意思是，它似乎只是作業。
根據您的評論：此時的 WebAssembly 標準通過使用原子指令來處理資料競爭。它們的訪問順序是順序一致的。在多執行緒的情況下，顯然記憶體分配器必須是執行緒安全的。不必單獨使用顯式執行緒專用堆疊（使用全域變數就足夠了，正如所寫的那樣），因為堆疊記憶體僅由執行緒本身管理。檢查原子指令的執行緒提議和實作狀態。也允許在非共享記憶體中使用原子指令。
一些實作可能會在進行非原子訪問和原子訪問時鎖定整個記憶體。這至少是因為規范不禁止更高的記憶體訪問保證。這意味著即使您在某個記憶體地址處創建了競爭，您也無法讀取不一致/撕裂的值。然而，這只是一種不應該被依賴的可能性。
uj5u.com熱心網友回復：
WASM 做出的選擇并不少見。拆分堆疊和多堆疊設計并不新鮮，并且一直與 C 和 C 兼容。這是 C 規范不足的故意結果，它總是允許“堆疊”變數存在于不可尋址的暫存器中。C 堆疊是抽象的，并且與底層執行環境的關系有限。
當 C 采用 C 11（C 遵循的 Java 記憶體模型）時，執行緒安全不是“自動的”，而僅適用于C 物件。從這個意義上說，“堆”不是一個物件，而是一個概念，實作安全是實作的責任。請注意，C 標準不要求性能。技術上允許使用全域鎖來保護堆。
在這種情況下，這意味著 WASM 應該將單獨的堆疊分開（如@Nikolay 指出的那樣）。這些堆疊占用的記憶體區域無關緊要，只要各個堆疊的各個片段在任何特定時刻不重疊即可。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/349082.html
標籤：c multithreading webassembly
上一篇：執行緒之間的對話
下一篇：如何解決多執行緒靜態變數遞增？