7 ms·

Multithreading Rust and Wasm

237 points by alexcrichton 8y ago

davidhyde 8y ago
Nice article. Now I know why the ManualResetEventSlim didn't work in c# Blazor. I wasn't aware that multi-threading in wasm was work in progress. The demo doesn't work on the standard latest firefox yet unfortunately (ver 63.0). Error: "this browser does not have SharedArrayBuffer support enabled". I guess this is a nightly firefox build thing.
- TomMarius 8y ago
  Not experimental, you need to enable SharedArrayBuffer in config because it's unsafe (Meltdown/Spectre) as of now, fixes are being worked on.
- sertorius 8y ago
  > this browser does not have SharedArrayBuffer support enabled It was disabled for Spectre safety reasons, but it can be re-enabled by navigating to "about:config", searching for "javascript.options.shared_memory" and toggling it to enabled. (But it was obviously disabled for good reason, so might want to enable it temporarily)
  - davidhyde 8y ago
    Thanks! That fixed that problem. Except now I get "this browser does not support passive wasm memory". There aren't any obvious javascript.options.* options for that.
    - alexcrichton 8y ago
      Oh dear sorry about this, it's a little too non-obvious how to see the demo! I've [pushed a small commit](https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bfc922014c58eeea3b3b62e3f7bed1 https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bf...) to update the demo to include information about browser requirements. Today this demo requires Firefox Nightly (64) and requires the `javascript.options.shared_memory` feature to be enabled. Other browsers will likely soon be able to run the demo as well!
      - davidhyde 8y ago
        Thanks, I'll give that a go!
- eksemplar 8y ago
  How are you finding Blazor in general? Is it worth looking into for smaller web apps or is it still far from production readiness?
  - davidhyde 8y ago
    It's definitely worth looking into. Although the authors of the library keep reminding the reader that blazor is not production ready I have found that it does everything I need it to. I found that it either works or doesn't at all if there is an unhandled exception in your code to you try to do something that is not supported. However, I haven't found the behavior to be non-deterministic (by that I mean flaky). I guess they may want to change the API before release. What is amazing is the ability to reference .net standard libraries.
jxub 8y ago
Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.
- jimmy1 8y ago
  > must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's telling of anything quite yet.
  - zellyn 8y ago
    It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
    - seanmcdirmid 8y ago
      WASM is the new and shiny also. I'm not even sure what to do with it ATM given that the DOM story still hasn't been figured out.
      - swsieber 8y ago
        Even though the DOM story hasn't been figured out, firefox has recently done work to make WASM <-> JS calls performant. So now things like Yew will probably be usable from a performance standpoint[0]. But apart from the DOM, it's good for CPU intensive things[1]. [0] Yew: https://github.com/DenisKolodin/yew https://github.com/DenisKolodin/yew [1] Refactoring a CPU intensive JS thing: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/ https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...
kodablah 8y ago
Nice, was just reading your issue [0]. I spent a bit of time the other day thinking how I could implement these thread ops on the JVM (JVM rambling henceforth, skip if not curious)... First, my project's output requires no runtime/dependencies, so I am restricted to JVM libs only. Memory is implemented as a ByteBuffer which does not have atomic access. I didn't quite understand the threads spec wrt data init on mem so I'll have to get clarification there (lock all mem? just go and pray?). The implementation will create four synthetic methods in the class: lock, unlock, wait, and wake. The class will have a field that is ConcurrentMap<Integer, int[]> where the key is the mem offset being locked, and the value is an array of mutable int refs size 2, the first being lock ref count and the second being wait ref count. Imports of shared memory pass that around along w/ the ByteBuffer. Lock will create/incr ref count and secure the lock via monitorenter on the int array (or fail if ref > 0 when just a try). Unlock will monitorexit and decr the count (removing from map if both ref counts are 0). All ops are done between this lock/unlock. Wait/wake is via wait/notify on the JVM, but JVM has no construct to say how many or if any threads were woken up on notify, so I have to keep the wait count. Incr/decr on the ref and wait vs notify (in a loop if > 1) is done as expected using wait() and notify() on the array itself. The lock, unlock, wait, and notify are done w/in concurrent map's compute making them atomic. Lock/wait lazily create the refs in the map. Unlock/notify, upon reaching 0 for both refs at the end, clear the refs out of the map. I have looked into existing JVM constructs and this seems to be the best way (I wish I could use Guava's Striped or the like, but I have no dependency/runtime requirement on outputted class files). Countdown latches, other locks, conditions, etc were all runtime overkill. I could have better performance than a boxed-int map with some extra code but wanted to keep it simple. Granted this is all pie-in-the-sky thinking, the impl will change it for sure. I am afraid to start an implementation because the proposal isn't further along yet (I really need some test cases in the suite to make me feel better). 0 - https://github.com/WebAssembly/threads/issues/106 https://github.com/WebAssembly/threads/issues/106
klarifie 8y ago
The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.
- jamesfmilne 8y ago
  The threads can all use the same SharedArrayBuffer for their memory, and thus a single address space. If the SharedArrayBuffer wasn’t shared, what’s the point of the atomic instructions, etc.
  - jamesfmilne 8y ago
    From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Memory backed by a SharedArrayBuffer will refer to the same memory!
    - klarifie 8y ago
      This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
      - pjmlp 8y ago
        And with the current trend of ongoing exploits actually safer than threads.
      - jamesfmilne 8y ago
        Nope they are using the same SharedArrayBuffer as their memory object.
      - nemaar 8y ago
amelius 8y ago
The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.
- monocasa 8y ago
  I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.
  - amelius 8y ago
    Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time! Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone? Also, language designers do not want a GC embedded in their assembly language; they want to implement it themselves, using their own constraints.
    - monocasa 8y ago
      > Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone? Because sandboxing in process is difficult otherwise. You can't allow the user to control code pointers, but for performance reasons you both need to have the raw pointers on the stack, and need to have semi privileged code in the same process just a function call away. Throwing everything into the process/hardware virtualization models doesn't fit this use case very well. It's why the VM in browsers carefully controls code pointers and is already pulled out to a semi sandboxed process. And I'll grant you that language implementors want raw stack access to implement their own performant GC; that just doesn't exist yet in wasm.
    - zamadatix 8y ago
      Can you clarify what you mean by "virtualization technology". It's a pretty broad term ranging from hardware assisted system virtualization to application virtualization to containerization. All of these types are run on servers all the time but each has very different performance and security characteristics.
eridius 8y ago
If the very first thread that's created has to do some bookkeeping that the other created threads rely on, what happens if you create a second thread at the same time as the first one? Or in other words, what happens if you don't instantiate the module on the browser's main thread at all, but instead just spin up 2 web workers that each instantiate the module? Whichever starts first will be thread 0, but what's to stop the other worker from entering its `start` function while the first worker is still busy initializing memory?
ilovecaching 8y ago
I'm extremely bullish about Rust riding wasm the same way Go rode the container space. This kind of work is exactly why I feel that way. It's uniquely positioned to take advantage of the benefits of wasm; building faster, safer applications on the browser. I look forward to the day when the web is Rust, although I guess if you're using Firefox, that's already partly true. :)
joelhooks 8y ago
Nik Graf releases this free egghead video course a couple weeks ago on Rust and WASM. https://egghead.io/courses/using-webassembly-with-rust https://egghead.io/courses/using-webassembly-with-rust

237 points by alexcrichton 8y ago

Nice article. Now I know why the ManualResetEventSlim didn't work in c# Blazor. I wasn't aware that multi-threading in wasm was work in progress. The demo doesn't work on the standard latest firefox yet unfortunately (ver 63.0). Error: "this browser does not have SharedArrayBuffer support enabled". I guess this is a nightly firefox build thing.

TomMarius 8y ago
Not experimental, you need to enable SharedArrayBuffer in config because it's unsafe (Meltdown/Spectre) as of now, fixes are being worked on.
sertorius 8y ago
> this browser does not have SharedArrayBuffer support enabled It was disabled for Spectre safety reasons, but it can be re-enabled by navigating to "about:config", searching for "javascript.options.shared_memory" and toggling it to enabled. (But it was obviously disabled for good reason, so might want to enable it temporarily)
- davidhyde 8y ago
  Thanks! That fixed that problem. Except now I get "this browser does not support passive wasm memory". There aren't any obvious javascript.options.* options for that.
  - alexcrichton 8y ago
    Oh dear sorry about this, it's a little too non-obvious how to see the demo! I've [pushed a small commit](https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bfc922014c58eeea3b3b62e3f7bed1 https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bf...) to update the demo to include information about browser requirements. Today this demo requires Firefox Nightly (64) and requires the `javascript.options.shared_memory` feature to be enabled. Other browsers will likely soon be able to run the demo as well!
    - davidhyde 8y ago
      Thanks, I'll give that a go!
eksemplar 8y ago
How are you finding Blazor in general? Is it worth looking into for smaller web apps or is it still far from production readiness?
- davidhyde 8y ago
  It's definitely worth looking into. Although the authors of the library keep reminding the reader that blazor is not production ready I have found that it does everything I need it to. I found that it either works or doesn't at all if there is an unhandled exception in your code to you try to do something that is not supported. However, I haven't found the behavior to be non-deterministic (by that I mean flaky). I guess they may want to change the API before release. What is amazing is the ability to reference .net standard libraries.

jxub 8y ago

Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.

jimmy1 8y ago
> must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's telling of anything quite yet.
- zellyn 8y ago
  It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
  - seanmcdirmid 8y ago
    WASM is the new and shiny also. I'm not even sure what to do with it ATM given that the DOM story still hasn't been figured out.
    - swsieber 8y ago
      Even though the DOM story hasn't been figured out, firefox has recently done work to make WASM <-> JS calls performant. So now things like Yew will probably be usable from a performance standpoint[0]. But apart from the DOM, it's good for CPU intensive things[1]. [0] Yew: https://github.com/DenisKolodin/yew https://github.com/DenisKolodin/yew [1] Refactoring a CPU intensive JS thing: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/ https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...

kodablah 8y ago

Nice, was just reading your issue [0]. I spent a bit of time the other day thinking how I could implement these thread ops on the JVM (JVM rambling henceforth, skip if not curious)... First, my project's output requires no runtime/dependencies, so I am restricted to JVM libs only. Memory is implemented as a ByteBuffer which does not have atomic access. I didn't quite understand the threads spec wrt data init on mem so I'll have to get clarification there (lock all mem? just go and pray?). The implementation will create four synthetic methods in the class: lock, unlock, wait, and wake. The class will have a field that is ConcurrentMap<Integer, int[]> where the key is the mem offset being locked, and the value is an array of mutable int refs size 2, the first being lock ref count and the second being wait ref count. Imports of shared memory pass that around along w/ the ByteBuffer. Lock will create/incr ref count and secure the lock via monitorenter on the int array (or fail if ref > 0 when just a try). Unlock will monitorexit and decr the count (removing from map if both ref counts are 0). All ops are done between this lock/unlock. Wait/wake is via wait/notify on the JVM, but JVM has no construct to say how many or if any threads were woken up on notify, so I have to keep the wait count. Incr/decr on the ref and wait vs notify (in a loop if > 1) is done as expected using wait() and notify() on the array itself. The lock, unlock, wait, and notify are done w/in concurrent map's compute making them atomic. Lock/wait lazily create the refs in the map. Unlock/notify, upon reaching 0 for both refs at the end, clear the refs out of the map. I have looked into existing JVM constructs and this seems to be the best way (I wish I could use Guava's Striped or the like, but I have no dependency/runtime requirement on outputted class files). Countdown latches, other locks, conditions, etc were all runtime overkill. I could have better performance than a boxed-int map with some extra code but wanted to keep it simple. Granted this is all pie-in-the-sky thinking, the impl will change it for sure. I am afraid to start an implementation because the proposal isn't further along yet (I really need some test cases in the suite to make me feel better). 0 - https://github.com/WebAssembly/threads/issues/106 https://github.com/WebAssembly/threads/issues/106

klarifie 8y ago

The article title is misleading. Wasm will not support multithreading, rather it'll be multiprocess via web workers and shared arrays for communication. It's not a single address space - code or data.

jamesfmilne 8y ago
The threads can all use the same SharedArrayBuffer for their memory, and thus a single address space. If the SharedArrayBuffer wasn’t shared, what’s the point of the atomic instructions, etc.
- jamesfmilne 8y ago
  From TFA: WebAssembly modules today are optionally associated with at most one instance of “linear memory”. In non-wasm parlance, you can put a stick of RAM into a wasm module. This WebAssembly.Memory is today always backed by an ArrayBuffer, but you’ll soon be able to flag a memory as “shared” which means it’s backed by SharedArrayBuffer instead. This subsequently means that the structured clone of a WebAssembly.Memory backed by a SharedArrayBuffer will refer to the same memory!
  - klarifie 8y ago
    This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
    - pjmlp 8y ago
      And with the current trend of ongoing exploits actually safer than threads.
    - jamesfmilne 8y ago
      Nope they are using the same SharedArrayBuffer as their memory object.
    - nemaar 8y ago

amelius 8y ago

The ultimate test would be to see if it is possible to implement an efficient concurrent GC in Rust+WASM. This might require memory fence instructions in WASM.

monocasa 8y ago
I thought you didn't have raw stack access in wasm, making efficient concurrent GCs impossible practically in native wasm. Hence the GC work to give a higher level API that can more easily be sandboxed.
- amelius 8y ago
  Virtualization technology is quite mature now, and allows running low-level code (that can access the stack) with safety. Servers run this type of code all the time! Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone? Also, language designers do not want a GC embedded in their assembly language; they want to implement it themselves, using their own constraints.
  - monocasa 8y ago
    > Why would we throw away these achievements, and turn WASM (with its potentially simple instruction set) into a complicated monster, that's prone to security problems through its complexity alone? Because sandboxing in process is difficult otherwise. You can't allow the user to control code pointers, but for performance reasons you both need to have the raw pointers on the stack, and need to have semi privileged code in the same process just a function call away. Throwing everything into the process/hardware virtualization models doesn't fit this use case very well. It's why the VM in browsers carefully controls code pointers and is already pulled out to a semi sandboxed process. And I'll grant you that language implementors want raw stack access to implement their own performant GC; that just doesn't exist yet in wasm.
  - zamadatix 8y ago
    Can you clarify what you mean by "virtualization technology". It's a pretty broad term ranging from hardware assisted system virtualization to application virtualization to containerization. All of these types are run on servers all the time but each has very different performance and security characteristics.

eridius 8y ago

If the very first thread that's created has to do some bookkeeping that the other created threads rely on, what happens if you create a second thread at the same time as the first one? Or in other words, what happens if you don't instantiate the module on the browser's main thread at all, but instead just spin up 2 web workers that each instantiate the module? Whichever starts first will be thread 0, but what's to stop the other worker from entering its `start` function while the first worker is still busy initializing memory?

ilovecaching 8y ago

I'm extremely bullish about Rust riding wasm the same way Go rode the container space. This kind of work is exactly why I feel that way. It's uniquely positioned to take advantage of the benefits of wasm; building faster, safer applications on the browser. I look forward to the day when the web is Rust, although I guess if you're using Firefox, that's already partly true. :)

joelhooks 8y ago

Nik Graf releases this free egghead video course a couple weeks ago on Rust and WASM. https://egghead.io/courses/using-webassembly-with-rust https://egghead.io/courses/using-webassembly-with-rust