SharedArrayBuffer, Atomics, and cross-origin isolation

Every postMessage either copies or hands off ownership. But multithreaded WASM needs a shared ring buffer that both the codec threads and JS can read and write at the same time — no copy, no handoff, just shared memory. And then it silently returns undefined in production.

What SharedArrayBuffer is

SharedArrayBuffer (SAB) is a block of memory that two or more threads can both read and write at the same time, with no copy. You build typed-array views over it on each thread and they see the same bytes:

// main thread
const sab = new SharedArrayBuffer(1024);
worker.postMessage({ sab }); // NOT transferred — shared

// worker
self.onmessage = e => {
  const view = new Int32Array(e.data.sab);
  view[0] = 42; // visible to main thread immediately
};

This is the foundation that makes multithreaded WebAssembly work in the browser — WASM’s linear memory is a SharedArrayBuffer when compiled with -pthread.

Why Atomics exist

Two threads writing the same SAB location without coordination is a data race — the result depends on timing and is undefined. Atomics provides operations the CPU guarantees are indivisible:

• Atomics.add(view, i, 1) — reads, adds, writes as one uninterruptible step. Two threads incrementing the same counter never lose an update.
• Atomics.compareExchange(view, i, expected, replacement) — the building block for lock-free data structures.
• Atomics.wait(view, i, expected) — blocks the calling thread until another thread calls Atomics.notify(view, i). A real blocking primitive — forbidden on the main thread, allowed inside workers. This wait/notify pair is how a WASM thread pool parks idle workers and wakes them when work arrives.

The relaxed memory model

SAB exposes a relaxed memory model: without atomics, one thread’s writes are not guaranteed visible to another thread in any particular order — the CPU and compiler may reorder non-atomic memory operations.

Atomic operations establish synchronisation edges (happens-before relationships) that make preceding non-atomic writes visible. The practical rule for application code:

1. Worker writes bulk data with plain typed-array writes.
2. Worker does one Atomics.store on a “data ready” flag.
3. Reader does one Atomics.load on the flag.
4. Once the reader sees the ready value, all the bulk writes are guaranteed visible.

Hand-rolling lock-free structures without this discipline produces bugs that appear only under load, only on certain CPUs.

The COOP/COEP gate

After the Spectre CPU vulnerability (2018), high-resolution shared memory became a security risk — a SAB-backed timer is precise enough to mount a side-channel attack. Browsers locked SAB behind two response headers the document must send:

• Cross-Origin-Opener-Policy: same-origin (COOP) — isolates your browsing-context group from other origins.
• Cross-Origin-Embedder-Policy: require-corp (COEP) — requires every cross-origin subresource to explicitly opt in to being embedded via Cross-Origin-Resource-Policy.

When both are present, self.crossOriginIsolated is true and SharedArrayBuffer is available. When they are not, SharedArrayBuffer is undefined and any code that needs it — multithreaded WASM especially — silently fails.

The cost: COEP breaks cross-origin images, fonts, and scripts that do not send the matching Cross-Origin-Resource-Policy header. Enabling isolation means auditing and fixing every third-party asset. Roll out COEP in report-only mode first (Cross-Origin-Embedder-Policy-Report-Only) to enumerate what would break before enforcing.

> typeof SharedArrayBuffer
'undefined'

> self.crossOriginIsolated
false

> performance.getEntriesByType('navigation')[0].responseHeaders
// Cross-Origin-Opener-Policy: same-origin
// Cross-Origin-Embedder-Policy: (not set)

[WASM] threads requested: 8
[WASM] SharedArrayBuffer unavailable - falling back to single-threaded
[WASM] init complete (single-threaded, 4.2x slower than target)