[wasm][post-MVP] shared everything threads #96629
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
ghost
added
the
lambdageek
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsThis issue tracks support for the WebAssembly post-MVP "shared everything threads" (aka thread spawn) proposal in .NET See #94351 for a summary of other WebAssembly proposals and their status. ProposalRepo: https://github.com/WebAssembly/shared-everything-threads Explainer or overview: https://github.com/WebAssembly/shared-everything-threads/blob/main/proposals/shared-everything-threads/Overview.md .NET Scenarios and User StoriesSupport multi-threaded .NET programs in web browsersSee #85592 Support multi-threaded .NET programs on WASI hostsAs a C# developer targeting a WASI host, I would like to compile and run multi-threaded .NET programs. Upstream dependencies: engines and toolchainsRequired WebAssembly engine supportExpected .NET targets or supported configurations: Desktop browsers + Mobile browsers + Node + WASI
Required WebAssembly toolchain supportWe need LLVM to support this for AOT. Opportunities and challengesShared-non-shared validationPreviously WebAssembly had a The jiterpreter will have to emit shared functions, too. It should be possible to take advantage of the new atomic table grow/get/set opcodes to populate the tables with jiterpreter-generated code. Realm local shared globals and functions in JSThe proposal adds thread local shared globals (that can also be exported to JS as "realm local" shared globals. We will likely need to take advantage of this for JS interop. non-shared globals/functions/tablesNeed to further investigate whether non- acquire-release memory model operationsThe proposal adds relaxed memory model annotations to some atomic memory access operations. We should be able to take advantage of these in .NET intrinsics thread spawn opcodeThe proposal adds a thread spawn opcode. We will likely not use it directly (the spawned threads do not intrinsically have POSIX thread semantics), but together with the rest of the proposal there should be enough here for a WASI libc to implement something like POSIX thread semantics that .NET could use to bootstrap our own threads with the expected semantics.
|
|
/cc @pavelsavara @kg |
lambdageek
removed
the
needs-area-label
This issue tracks support for the WebAssembly post-MVP "shared everything threads" (aka thread spawn) proposal in .NET
See #94351 for a summary of other WebAssembly proposals and their status.
Proposal
Repo: https://github.com/WebAssembly/shared-everything-threads
Explainer or overview: https://github.com/WebAssembly/shared-everything-threads/blob/main/proposals/shared-everything-threads/Overview.md
.NET Scenarios and User Stories
Support multi-threaded .NET programs in web browsers
See #85592
Support multi-threaded .NET programs on WASI hosts
As a C# developer targeting a WASI host, I would like to compile and run multi-threaded .NET programs.
Upstream dependencies: engines and toolchains
Required WebAssembly engine support
Expected .NET targets or supported configurations: Desktop browsers + Mobile browsers + Node + WASI
Required WebAssembly toolchain support
We need LLVM to support this for AOT.
Opportunities and challenges
Shared-non-shared validation
Previously WebAssembly had a
sharedflag on linear memories, the proposal adds asharedflag on globals, functions, tables, etc. It also introduces a new restriction: shared functions (globals, tables) cannot access non-shared function (globals, tables, memories). As noted in the Overview, one approach that C toolchains may take is to mark everything as shared: https://github.com/WebAssembly/shared-everything-threads/blob/main/proposals/shared-everything-threads/Overview.md#how-will-toolchains-need-to-changeThe jiterpreter will have to emit shared functions, too. It should be possible to take advantage of the new atomic table grow/get/set opcodes to populate the tables with jiterpreter-generated code.
Realm local shared globals and functions in JS
The proposal adds thread local shared globals (that can also be exported to JS as "realm local" shared globals.
Additionally JS hosts will have a way to construct a shared function object that can be initialized differently in each realm.
We will likely need to take advantage of this for JS interop.
non-shared globals/functions/tables
Need to further investigate whether non-
sharedwasm constructs make sense for .NET (perhaps as an optimization for JS interop avoiding realm-local shared functions)acquire-release memory model operations
The proposal adds relaxed memory model annotations to some atomic memory access operations. We should be able to take advantage of these in .NET intrinsics
thread spawn opcode
The proposal adds a thread spawn opcode. We will likely not use it directly (the spawned threads do not intrinsically have POSIX thread semantics), but together with the rest of the proposal there should be enough here for a WASI libc to implement something like POSIX thread semantics that .NET could use to bootstrap our own threads with the expected semantics.
Compatibility with WASI preview1+threads
WASI hosts implement WASI preview1 and the wasi-threads proposal as another mechanism for spawning threads. Depending on engine uptake (and user scenarios) we might have to support both options. That probably means compiling against a different libc and with different toolchain compiler flags. Likewise our own tools would need to take flags to specify if we want "shared everything" or "preview1+threads"
WasmGC
In some sense the point of this proposal is to add threading for WasmGC. Heap types also get a
sharedannotation. If we end up working on #94420 we would need to mark our heap types as shared.The text was updated successfully, but these errors were encountered: