Multi-threading and Atomics

[kanishkarj]

Hi, I really excited about WASI and what it's trying to achieve. I looked around for this, but couldn't find any mention of it. What is the status of multi-threading and Atomics in WASI? I saw that Chrome added support to threading in WASM. I just was curious about its status in WASI, and if it's not there yet how long down the line can we expect to have it there?

Thank you

[sunfishcode]

The current state is that the WebAssembly core spec for threads is designed around Web Worker-style threading, the current thinking is that this model isn't suitable for use outside the Web or similar runtimes. See the following issues for some background discussion:

WebAssembly/threads#8
WebAssembly/threads#95
WebAssembly/threads#138

When the core spec adds better support for threading in non-Web environments, I expect we'll quickly add WASI APIs for creating and managing threads.

[tlively]

Those threads mostly concern the future native threading proposal, but in WebAssembly/threads#138, @lukewagner wrote,

I think it would make sense for WASI to also define a portable thread creation API too (that could be polyfilled in a browser with workers).

I agree with Luke's thinking there that in principle there is nothing stopping WASI from having a standard API for creating and manipulating threads using the current proposal. Is there a WASI design goal that would prevent that from working, or is it just a matter of not spending time on a solution based on the current proposal when we expect a better proposal to come along eventually?

[sunfishcode]

I'm not aware of any conflicts with design goals. It's mainly about not wanting to get too far away from where we expect the core spec will go, and an optimistic assumption that the work to enable native threads will happen on a reasonable timeframe.

A key question is: is there one wasm instance per thread (like workers do), or just one wasm instance that can be running multiple threads (as the "native" thread proposals typically suggest)? That affects whether or not we run the wasm start function on thread creation. And it affects whether globals are thread-local or not -- and since we use a global for the linear-memory stack pointer, if it isn't thread-local we need to do something different.

Another question is, if a module has exports or registers callbacks and gets called on a new thread, if it needs a linear-memory stack, when does it allocate the new stack? That's a question for native threads too, though I imagine they'll need a different answer.

[lygstate]

I'm not aware of any conflicts with design goals. It's mainly about not wanting to get too far away from where we expect the core spec will go, and an optimistic assumption that the work to enable native threads will happen on a reasonable timeframe.

A key question is: is there one wasm instance per thread (like workers do), or just one wasm instance that can be running multiple threads (as the "native" thread proposals typically suggest)? That affects whether or not we run the wasm start function on thread creation. And it affects whether globals are thread-local or not -- and since we use a global for the linear-memory stack pointer, if it isn't thread-local we need to do something different.

any discuss result， I prefer one wasm instance per thread (like workers do), and the native one can implement base on that， can we use multiple memory to sharing wasm instance across threads？ for thread
local variable， can we use shared memory to do that？

Another question is, if a module has exports or registers callbacks and gets called on a new thread, if it needs a linear-memory stack, when does it allocate the new stack? That's a question for native threads too, though I imagine they'll need a different answer.

[sunfishcode]

can we use multiple memory to sharing wasm instance across threads?

Typical shared-memory programming models have a single address space that all threads share, which in general would not be compatible with multiple wasm memories.

for thread local variable， can we use shared memory to do that?

Yes, thead-local variables typically do use shared memory.

[lygstate]

can we use multiple memory to sharing wasm instance across threads?

Typical shared-memory programming models have a single address space that all threads share, which in general would not be compatible with multiple wasm memories.

From my point of view, webwoker are more like a process than a thread, even though we name it as a thread. Because of webassembly are inherently isolation of each webassembly/webworker instance, the sharedmemory also need postMessage to getting them to be shared, from this point of view, in web there is no native threads at all, they are all process。
And in threads future, I proposal add native threads support in a single WebWorker, so that we can unify the threads between WebWorker and native embbed nodejs environment.
I think this proposal shoud be some webassembly instruction for creating threads, just like a real CPU does. And these instruction can also helps creating multiple stack(coroutine) program like we did on real CPU.

for thread local variable， can we use shared memory to do that?

Yes, thead-local variables typically do use shared memory.

[Julio-Guerra]

Hello,

I personally don't need the full pthread library support. So is there any reason not to be able to compile the C library with the shared memory model (ie. what clang's driver option -pthread does)?

[sunfishcode]

The C library itself depends on pthread support to make itself thread-safe when compiled with the shared memory model.

[sunfishcode]

As of WebAssembly/wasi-libc#518, wasi-libc now has a stub pthread.h header file.

Support for threads in the component model is discussed here. It depends on core-wasm langauge features being developed in the shared-everything threads proposal.

If there are any further questions here, please file new issues!