Master SharedArrayBuffer, Atomics API, COOP/COEP headers, and multi-threaded WebAssembly with web workers.
0 / 5 completed
1 / 5
What is required in a browser to use WebAssembly threads via SharedArrayBuffer?
Cross-origin isolation is mandatory because SharedArrayBuffer was re-enabled after the Spectre mitigations. Both COOP and COEP headers must be set so the browser can safely expose shared memory between origins without creating side-channel timing attacks.
2 / 5
What does Atomics.wait() do in a Web Worker context?
Atomics.wait is a blocking primitive — it can only be called from a Worker (never the main thread, where it throws). The worker suspends until another thread calls Atomics.notify() on the same index, implementing low-level synchronisation like a futex.
3 / 5
What is the role of Atomics.notify()?
Atomics.notify accepts the SharedArrayBuffer view, index, and an optional count of threads to wake. It is the counterpart to wait(), enabling producer-consumer patterns where one worker signals others that new data is available.
4 / 5
How does a WebAssembly module share memory with JavaScript Web Workers?
Shared WebAssembly.Memory: you create one WebAssembly.Memory object with shared: true, then pass it to the WebAssembly.instantiate call in every worker. All workers see the same linear memory and can use Atomics operations on it for thread-safe coordination.
5 / 5
Why must Atomics.store() be used instead of a plain assignment when communicating between threads on a SharedArrayBuffer?
Memory ordering: JavaScript engines and CPUs can reorder non-atomic writes for performance. Atomics.store emits the appropriate memory barrier so that when another thread calls Atomics.load, it observes all writes that happened before the store, preventing subtle data-race bugs.