Some discussion here: https://github.com/WebAssembly/threads/issues/9
tl;dr if WASM shared memory is specified to follow the same rules as SharedArrayBuffer, then atomic operations are sequentially consistent. Normal memory accesses in the presence of data races may be inconsistent, but they are still constrained (e.g. they must obey happens-before relationships).
In WebAssembly Threads ready to try in Chrome 70WebAssembly
threads
WebAssembly2017–2026
WebAssembly / threads
threads
Threads and Atomics in WebAssembly
24Distinct people
26Mentions
0Explicit recommenders
772GitHub stars
What to know before exploring
What it is
Threads and Atomics in WebAssembly
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- webassembly/proposals · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2017-05-15 18:41:17 UTC to 2026-05-27 19:41:44 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Threads Proposal for WebAssembly
This repository is a clone of github.com/WebAssembly/spec/. It is meant for
discussion, prototype specification and implementation of a proposal to threads
support to WebAssembly.
See the overview for a summary of the proposal.
A formatted version of the spec with proposed changes is available here:
webassembly.github.io/threads.
Original README from upstream repository follows...
spec
This repository holds the sources for the WebAssembly draft specification
(to seed a future
WebAssembly Working Group),
a reference implementation, and the official testsuite.
A formatted version of the spec is available here:
webassembly.github.io/spec,
Participation is welcome. Discussions about new features, significant semantic
changes, or any specification change likely to generate substantial discussion
should take place in
the WebAssembly design repository
first, so that this spec repository can remain focused. And please follow the
guidelines for contributing.
citing
For citing WebAssembly in LaTeX, use this bibtex file.
Read the full README on GitHubWhat Hacker News says
5 sourcesQuick notes... The threads feature is in proposed status vs others that are in implementation status [0], but I assume this has been implemented before things like multi-value. I wonder why threads first, I assume just for experimentation. It should be noted that threads are essentially atomic memory accesses and wait/notify, nothing for starting a worker inside of WASM or anything, that is still in JS land. The test cases don't appear to include wait/wake nor does the test case interpreter that I saw [1]. Also, "Report issues" in the blog post links to https://TBD.
0 - https://github.com/WebAssembly/proposals
1 - https://github.com/WebAssembly/threads
In WebAssembly Threads ready to try in Chrome 70Nice, 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
Read the rest
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
I don't think the thread proposal will change anything here. Like the existing memory instructions, the atomic instructions proposed for threads (https://github.com/WebAssembly/threads/blob/master/proposals...) don't take a linear memory parameter. That means they operate on the same default linear memory.
In Calls between JavaScript and WebAssembly are finally fastWASM will have more low level support.
https://github.com/WebAssembly/threads/blob/master/proposals...
In Web Assembly and Go: A look to the future