Multi-threading?

[Iainmon]

How would I go about creating threads in AssemblyScript? I am having trouble understanding the documentation.

[dcodeIO]

To enable threading one would compile with --enable threads --sharedMemory SIZE and share the memory instance between modules. However, the default runtimes do not currently support threading, so using threads isn't straight forward at this point and requires resorting to low-level code using the respective WebAssembly instructions directly.

A possible scenario at this point is to have a main thread that manages memory (--runtime half/full) and multiple workers (--runtime none) that perform computation on raw data provided and kept alive by the main thread, which should be safe as long as the workers do not interfere with memory management or GC and do not have own static data (no new, no stdlib, no strings etc.).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[reconman]

Seems like multithreading support was added in Chrome 74 by default, and I can't really find anything on how to use multithreading in AssemblyScript other than using Web Workers, which I want to avoid.

So, is there any update on this topic?

[dumblob]

Any update on this?

I was planning to use threading with AssemblyScript, but this issue makes me wonder whether I shouldn't rather stick with low-level WASM instead (which I wanted to avoid with the fear I would screw something up because I don't know the internals of AssemblyScript).

[Ciantic]

Please re-open. I was specifically looking for multi-threading support as well. Not sure how feasible it is to implement though but some clarification why it's not would be nice. Thanks!

[MaxGraey]

creating threads in WebAssembly happening on host side. AseemblyScript support atomics and shared memory but doesn't support thread safety for standard library yet. So if you avoid std allocs in shared memory it will be work. See example:
https://blog.feather.systems/mandelbrot

[dcodeIO]

To give an update on the implementation details, the missing building block is still to make the runtime threading-aware, so a shared memory can be used. Right now, the runtime uses some globals, and globals are not shared across threads (only memory can be). With the globals moved to memory so these become shared and all threads see the same state, the next challenge would be to think about where and when to run the GC (probably on the main thread only), and locking / synchronization. In general the problem is that JS/TS hasn't been designed for this and one would use a WebWorker or similar there, so we'll either have to come up with something novel, or investigate how to wrap something safe into a WebWorker like API or similar.

[MaxGraey]

Well I like approach of Rayon. I did something similar for Swift in the past but without iterators. Also it was pretty similar to tbb::parallel_for. But it also need something more generic and abstract like Software Transactional Memory (SMT) or Actor model. In general, it is a matter of approach for whole language that requires research and working prototypes

[trusktr]

@MaxGraey any idea why the multi-threaded SIMD example is slower than the single threaded optimized examples? I'm on my Pixel 4 phone.