1 of 15

Conrad Watt

Threads

2 of 15

What is the threads proposal?

​

  • In a nutshell - enabling concurrent access of memory��
  • Importantly, we’re not adding a way to create new threads, just describing how to support concurrent memory access for Wasm programs running across multiple host threads (e.g. Web Workers)

3 of 15

The basics

​

  • A new shared attribute for memories that allows them to be shared across module instances in multiple threads
    • On the Web, shared memories can be postMessage’d by reference��
  • A suite of sequentially consistent atomic operations
    • load, store, CAS, wait, notify, and fence

4 of 15

The basics

​

  • We don’t allow instantiated state to be shared across threads, except for shared memories�
  • Implies that source programs compiled to Wasm+threads must do some coordination in JavaScript to instantiate copies of code in each Web worker
    • postMessage transfers shared memory reference to each worker�
  • We have a post-MVP plan to improve on this

5 of 15

What’s the current situation with threads?

​

  • Quite widely implemented already
    • effectively shipped in all major browsers as of December 2021
    • with the addition of fence, no outstanding MVP design questions��
  • The main remaining advancement hurdles are spec-procedural

6 of 15

Requirements for phase 3

Entry requirements:

Test suite has been updated to cover the feature in its forked repo.

The test suite should run against some implementation, though it need not be the reference interpreter.

Formal notation in the spec need not be updated.

7 of 15

Satisfying the phase 3 requirements

  • Updating the wast format to support multi-threaded tests�
    • Introduce a thread block that describes WebAssembly modules and assertions running in a sub-thread�
    • We have a proof-of-concept mapping to Web Workers implemented as an extension of JS test extraction in a branch of the spec repository (extract-js-poc)�
  • Implementing support for all atomic operations in the reference interpreter (merge with main branch pending for wait/notify).�
  • Writing a basic suite of concurrent tests based on the ”periodic table” of “systematic” tests by Alglave et al.

8 of 15

Example: MP

[X] := 1

[Y] := 1

r1 := [Y]

r2 := [X]

r1 = 1 and r2 = 0 ???

9 of 15

10 of 15

Example: SB

[X] := 1

r1 := [Y]

[Y] := 1

r2 := [X]

r1 = 0 and r2 = 0 ???

11 of 15

Poll for phase 3

Entry requirements:

Test suite has been updated to cover the feature in its forked repo.

The test suite should run against some implementation, though it need not be the reference interpreter.

Formal notation in the spec need not be updated.

12 of 15

Next steps: phase 4

  • Really is just about hacking on the formal spec, and maybe sanding off edges for the test tooling�
  • Talking about ways to share the burden of this�

13 of 15

Post-MVP

  • Currently we only support SC atomics
    • these are very expensive!�
  • A source program with release-acquire atomics has all of them upgraded to SC when compiling to Wasm�
  • On x86, this means that such stores are compiled to (locked) XCHG instead of the expected MOV�
  • On ARMv7, implies an extra barrier on such stores�

14 of 15

Post-MVP

  • So step 1 for more performance - add release-acquire atomics in Wasm�
  • Analogous but more complicated issue/solution for relaxed atomics and concurrent Java programs�
  • Not clear how visible these performance wins will be - other issues like the amount of JS interoperation in compiled code may be dominating�
    • JS proposals like GrowableSharedArrayBuffer will improve things here�

15 of 15

Post-MVP

  • Add a shared attribute to other constructs (functions, globals, GC structs) to allow them to be shared across threads
    • Strong analogy to the JS shared struct proposal�
  • Then, add a proper fork instruction to Wasm so threads can be created without relying on the host