locking/semaphores/cond-vars should be based on atomics rather than provided by the wasm host

[programmerjake]

afaict pthread_mutex/rwlock/etc. are all fully implementable within wasm by just using the atomic operations with atomic wake/wait

[sbc100]

Indeed, emscripten does it this way today.

[AlexEne]

That's the plan, yes.

The current proposal wants to add the thread_spawn function only. Even join could be implemented with existing atomics. The text isn't clear as I've added that join section. I'll update it to be correct..

[kleisauke]

Wouldn't thread_spawn collide with the task.new instruction within the stack switching proposal? IIUC, the only difference would be the threading model, the stack switching proposal can make use of M:N threading, whereas this proposal is 1:1.

[sbc100]

Creating an new thread (in this context) is going to be quite different to creating a new stack within the same thread. One major difference which is very observable to wasm is that each thread gets in own instance (at least in the current model). The only thing the two threads will share is the memory.. all tables and globals, for example, will not be shared between threads. By contrast, stack.new creates a new execution context in the same instance.

For this initial version of wasi-native-threads we also want to use a function import for thread creation, rather than adding a new instruction, since we don't want to block any core wasm changes, and instead want some thing that can be make to work today, in similar fashion to the way we use workers to implemented wasm threads on the web.

In the long run there could well be a core wasm thread creation API but it would be much larger effort and there are many unanswered questions around exactly how that might work.

[kleisauke]

Thanks for the clarification! I actually hadn't read the full spec of stack switching proposal, it looks like it's based on the N:1 threading model in retrospect. I was confused by the mention of green threads in the spec, since that could be based either on M:N (e.g. Erlang processes) or N:1 (e.g. Java), where the former model would provide parallelism.

PR WebAssembly/stack-switching#17 would rename task to fiber, which would clarify for me that it's cooperative multitasking instead of preemptive multitasking.